osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

2 participants
516 discussions

Re: [PATCH net v2] gtp: serialize PDP context updates
by Jakub Kicinski 11 Aug '26

11 Aug '26

On Sat, 8 Aug 2026 20:43:22 +0800 Qing Ming wrote: > Subject: [PATCH net v2] gtp: serialize PDP context updates This patch does not apply to net/main, please rebase and repost.

1 0

[PATCH net] gtp: serialize PDP deletion with link teardown
by Qing Ming 06 Aug '26

06 Aug '26

PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU. Running both paths concurrently can therefore make both paths delete the same PDP context. On a KASAN-enabled kernel, a reproducer racing DELPDP against RTM_DELLINK triggered: Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp] RBP: dead000000000122 The second deletion dereferenced the poisoned hlist pprev pointer. Take RTNL around the DELPDP lookup and deletion so that PDP creation, generic-netlink deletion and link teardown use the same serialization domain. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Qing Ming <a0yami(a)mailbox.org> --- drivers/net/gtp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 427b91aca50d..7c4a99e2fd52 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -2127,6 +2127,8 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) if (!info->attrs[GTPA_VERSION]) return -EINVAL; + rtnl_lock(); + rcu_read_lock(); pctx = gtp_find_pdp(sock_net(skb->sk), info->attrs); @@ -2147,6 +2149,7 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; } -- 2.53.0

1 0

[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

💥 Crush the {NCP-BC} today with our No.1 rated April 2026 exam dump kit!
by george.taylor23587＠gmail.com 28 Apr '26

28 Apr '26

Looking for the No.1 shortcut to NCP-BC certification success? 🔥 In April 2026, the secret isn't just studying harder it's studying smarter. If the {NCP-BC} is your next big move, don’t risk a retake. Grab the No.1 student-verified materials and clear your exam faster with confidence! 🏆 At ValidExamDumps, we’ve found the code for Nutanix success. Our latest released exam dumps features real-pattern questions specifically updated for the current NCP-BC testing window. 💻 What makes us the No.1 preparation partner? ✅ Actual Questions: Precise dumps for NCP-BC that reflect the real test. 🔥 Instant Updates: Fresh April 2026 content for all Nutanix tracks. ⚡ Proven Results: The No.1 trusted source for IT pros globally. Stop guessing and start passing. 🎯 🔗 Access your NCP-BC Study Bank here: https://www.validexamdumps.com/nutanix/ncp-bc-dumps 💎 Grab the No.1 NCP-BC Actual Dumps: https://www.validexamdumps.com/nutanix/ncp-bc-exam-questions #ValidExamDumps #No1Dumps #NCP-BC #Nutanix #CertificationSuccess #April2026 #ITCareer #ExamPrep

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs