osmocom-net-gprs July 2026

osmocom-net-gprs@lists.osmocom.org

7 participants
7 discussions

[PATCH net] gtp: check skb_pull_data() return in gtp1u_send_echo_resp()
by Xiang Mei (Microsoft) 22 Jul '26

22 Jul '26

gtp1u_send_echo_resp() ignores skb_pull_data()'s return value. Its caller gtp1u_udp_encap_recv() only guarantees 16 bytes (udphdr + gtp1_header), but the pull requests 20 (gtp1_header_long + udphdr). For a 16-19 byte echo request the pull fails and returns NULL without advancing skb->data; execution continues, and the following skb_push() plus the IP header pushed by iptunnel_xmit() move skb->data below skb->head, tripping skb_under_panic(). Fix it by dropping the packet when skb_pull_data() fails. skbuff: skb_under_panic: ... kernel BUG at net/core/skbuff.c:214! Call Trace: skb_push (net/core/skbuff.c:2648) iptunnel_xmit (net/ipv4/ip_tunnel_core.c:82) gtp_encap_recv (drivers/net/gtp.c:701 drivers/net/gtp.c:808 drivers/net/gtp.c:920) udp_queue_rcv_one_skb (net/ipv4/udp.c:2388) ... Kernel panic - not syncing: Fatal exception in interrupt Fixes: 9af41cc33471 ("gtp: Implement GTP echo response") Reported-by: AutonomousCodeSecurity(a)microsoft.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Xiang Mei (Microsoft) <xmei5(a)asu.edu> --- drivers/net/gtp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index a60ef32b35b8..f8c7b532b10c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -669,8 +669,9 @@ static int gtp1u_send_echo_resp(struct gtp_dev *gtp, struct sk_buff *skb) return -1; /* pull GTP and UDP headers */ - skb_pull_data(skb, - sizeof(struct gtp1_header_long) + sizeof(struct udphdr)); + if (!skb_pull_data(skb, sizeof(struct gtp1_header_long) + + sizeof(struct udphdr))) + return -1; gtp_pkt = skb_push(skb, sizeof(struct gtp1u_packet)); memset(gtp_pkt, 0, sizeof(struct gtp1u_packet)); -- 2.43.0

2 1

[PATCH net-next] Revert "gtp: annotate PDP lookups under RTNL"
by Simon Horman 21 Jul '26

21 Jul '26

This reverts commit 0be5c3f0fbef3679f50f345b9237b8f9ea5de4e9. Commit 0be5c3f0fbef ("gtp: annotate PDP lookups under RTNL") added a lockdep_rtnl_is_held condition to hlist_for_each_rcu() loops to help insure that RTNL is held. Unfortunately, as pointed out by Pablo Neira Ayuso, the PDP context list is actually protected by the genetlink mutex. And so the condition is incorrect. Compile tested only. Signed-off-by: Simon Horman <horms(a)kernel.org> --- drivers/net/gtp.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 4ad9528322c45c4511a2cde02d3ca7c8faea3758..a60ef32b35b8255a17bed3fbc6ce19f26b3ba3a8 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -151,8 +151,7 @@ static struct pdp_ctx *gtp0_pdp_find(struct gtp_dev *gtp, u64 tid, u16 family) head = &gtp->tid_hash[gtp0_hashfn(tid) % gtp->hash_size]; - hlist_for_each_entry_rcu(pdp, head, hlist_tid, - lockdep_rtnl_is_held()) { + hlist_for_each_entry_rcu(pdp, head, hlist_tid) { if (pdp->af == family && pdp->gtp_version == GTP_V0 && pdp->u.v0.tid == tid) @@ -169,8 +168,7 @@ static struct pdp_ctx *gtp1_pdp_find(struct gtp_dev *gtp, u32 tid, u16 family) head = &gtp->tid_hash[gtp1u_hashfn(tid) % gtp->hash_size]; - hlist_for_each_entry_rcu(pdp, head, hlist_tid, - lockdep_rtnl_is_held()) { + hlist_for_each_entry_rcu(pdp, head, hlist_tid) { if (pdp->af == family && pdp->gtp_version == GTP_V1 && pdp->u.v1.i_tei == tid) @@ -187,8 +185,7 @@ static struct pdp_ctx *ipv4_pdp_find(struct gtp_dev *gtp, __be32 ms_addr) head = &gtp->addr_hash[ipv4_hashfn(ms_addr) % gtp->hash_size]; - hlist_for_each_entry_rcu(pdp, head, hlist_addr, - lockdep_rtnl_is_held()) { + hlist_for_each_entry_rcu(pdp, head, hlist_addr) { if (pdp->af == AF_INET && pdp->ms.addr.s_addr == ms_addr) return pdp; @@ -223,8 +220,7 @@ static struct pdp_ctx *ipv6_pdp_find(struct gtp_dev *gtp, head = &gtp->addr_hash[ipv6_hashfn(ms_addr) % gtp->hash_size]; - hlist_for_each_entry_rcu(pdp, head, hlist_addr, - lockdep_rtnl_is_held()) { + hlist_for_each_entry_rcu(pdp, head, hlist_addr) { if (pdp->af == AF_INET6 && ipv6_pdp_addr_equal(&pdp->ms.addr6, ms_addr)) return pdp;

3 2

[PATCH net v3] gtp: parse extension headers before reading inner protocol
by Zhixing Chen 21 Jul '26

21 Jul '26

3 4

Re: [PATCH net-next] gtp: annotate PDP lookups under RTNL
by Simon Horman 09 Jul '26

09 Jul '26

On Wed, Jul 01, 2026 at 08:39:25PM +0800, Runyu Xiao wrote: > The GTP PDP lookup helpers are shared by RCU-protected data and report > paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The > helpers walk RCU hlists, but they do not currently pass the RTNL > condition for the control-path lookups. > > Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing > RCU-reader callers remain valid because the RCU-list macros also accept > an active RCU read-side section; the added condition only documents the > non-RCU protection already used by RTNL control paths. > > This was found by our static analysis tool and then manually reviewed > against the current tree. The dynamic triage evidence is a > target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited > to documenting the existing protection contract. > > This is a lockdep annotation cleanup. It does not change PDP lifetime or > hash updates. > > Signed-off-by: Runyu Xiao <runyu.xiao(a)seu.edu.cn> Reviewed-by: Simon Horman <horms(a)kernel.org> There is an AI-generated review of this patch available on sashko.dev. While I don't believe that the issues raised there should impede progress of this patch you may want to look into them as possible follow-up. ...

3 6

Re: [PATCH net-next] gtp: annotate PDP lookups under RTNL
by patchwork-bot+netdevbpf＠kernel.org 08 Jul '26

08 Jul '26

Hello: This patch was applied to netdev/net-next.git (main) by Paolo Abeni <pabeni(a)redhat.com>: On Wed, 1 Jul 2026 20:39:25 +0800 you wrote: > The GTP PDP lookup helpers are shared by RCU-protected data and report > paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The > helpers walk RCU hlists, but they do not currently pass the RTNL > condition for the control-path lookups. > > Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing > RCU-reader callers remain valid because the RCU-list macros also accept > an active RCU read-side section; the added condition only documents the > non-RCU protection already used by RTNL control paths. > > [...] Here is the summary with links: - [net-next] gtp: annotate PDP lookups under RTNL https://git.kernel.org/netdev/net-next/c/0be5c3f0fbef You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html

2 1

[PATCH net v2] gtp: parse extension headers before reading inner protocol
by Zhixing Chen 08 Jul '26

08 Jul '26

2 3

[PATCH net] gtp: parse extension headers before reading inner protocol
by Zhixing Chen 03 Jul '26

03 Jul '26

GTPv1-U packets may carry a chain of extension headers before the inner IP packet. The receive path already parses and skips these extension headers, but it currently reads the inner protocol before doing so. As a result, the first extension header byte is interpreted as the inner IP version. Packets with extension headers are then dropped before PDP lookup. Parse the extension header chain before calling gtp_inner_proto(), so the inner protocol is read from the actual inner IP header. Signed-off-by: Zhixing Chen <running910(a)gmail.com> --- I noticed this while running a few GTP tunnel tests with a veth pair and a peer network namespace. The commands below only set up a small GTPv1-U demo and verify that the plain tunnel works as expected: ip link add vroot type veth peer name vpeer ip a a 172.0.0.1/24 dev vroot ip link set vroot up ip a a 172.99.0.1/32 dev lo gtp-link add gtp0 ip 172.0.0.1 & gtp-tunnel add gtp0 v1 200 100 172.99.0.2 172.0.0.2 ip r a 172.99.0.2/32 dev gtp0 ip link set gtp0 mtu 1500 ip netns add nspeer ip link set vpeer netns nspeer ip netns exec nspeer ip a a 172.0.0.2/24 dev vpeer ip netns exec nspeer ip link set vpeer up ip netns exec nspeer ip a a 172.99.0.2/32 dev lo ip netns exec nspeer ip link set lo up ip netns exec nspeer gtp-link add gtp1 ip 172.0.0.2 & ip netns exec nspeer gtp-tunnel add gtp1 v1 100 200 172.99.0.1 172.0.0.1 ip netns exec nspeer ip r a 172.99.0.1/32 dev gtp1 ip netns exec nspeer ip link set gtp1 mtu 1500 With this setup, plain traffic between 172.99.0.1 and 172.99.0.2 goes through the GTP tunnel. After that, I used a small sender in the peer namespace to build two UDP/2152 packets for the root namespace GTP endpoint. Both packets use TEID 200 and carry an inner UDP packet from 172.99.0.2:12345 to 172.99.0.1:9999. The first packet is a plain GTPv1-U T-PDU. The second packet carries the same inner UDP packet after a GTP extension header. Before this fix, a receiver bound to 172.99.0.1:9999 only receives the plain packet: root@vm:/# python gtp_nsroot_recv.py listening on 172.99.0.1:9999 received #1 from ('172.99.0.2', 12345): b'plain' After this fix, it receives both packets: root@vm:/# python gtp_nsroot_recv.py listening on 172.99.0.1:9999 received #1 from ('172.99.0.2', 12345): b'plain' received #2 from ('172.99.0.2', 12345): b'extension' --- drivers/net/gtp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index a60ef32b35b8..4a8b00548673 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -826,6 +826,10 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) if (!pskb_may_pull(skb, hdrlen)) return -1; + if (gtp1->flags & GTP1_F_EXTHDR && + gtp_parse_exthdrs(skb, &hdrlen) < 0) + return -1; + if (gtp_inner_proto(skb, hdrlen, &inner_proto) < 0) { netdev_dbg(gtp->dev, "GTP packet does not encapsulate an IP packet\n"); return -1; @@ -840,10 +844,6 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return 1; } - if (gtp1->flags & GTP1_F_EXTHDR && - gtp_parse_exthdrs(skb, &hdrlen) < 0) - return -1; - return gtp_rx(pctx, skb, hdrlen, gtp->role, inner_proto); } -- 2.34.1

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs July 2026