In gtp_create_sockets(), gtp->sk_created is set to true before gtp->sk0 and gtp->sk1u are assigned. A concurrent GTP Echo Response packet on another CPU observes sk_created == true and dereferences the still-NULL gtp->sk0 in gtp0_handle_echo_resp(), causing a kernel panic.
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:gtp_encap_recv (drivers/net/gtp.c:542 gtp0_handle_echo_resp) Call Trace: <IRQ> udp_queue_rcv_one_skb ip_protocol_deliver_rcu ip_local_deliver Kernel panic - not syncing: Fatal exception in interrupt
Reorder the assignments so that gtp->sk0 and gtp->sk1u are fully visible before gtp->sk_created is set to true. This ensures no concurrent packet path can observe the flag without valid socket pointers.
Fixes: b20dc3c68458 ("gtp: Allow to create GTP device without FDs") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) xmei5@asu.edu Reported-by: Cen Zhang (Microsoft) blbllhy@gmail.com Signed-off-by: Cen Zhang (Microsoft) blbllhy@gmail.com --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 9a12cc53da00..2b5a8f6d24d0 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1456,9 +1456,9 @@ static int gtp_create_sockets(struct gtp_dev *gtp, const struct nlattr *nla, return PTR_ERR(sk1u); }
- gtp->sk_created = true; gtp->sk0 = sk0; gtp->sk1u = sk1u; + gtp->sk_created = true;
return 0; }
On Sat, Aug 15, 2026 at 11:52:05PM -0400, Cen Zhang (Microsoft) wrote:
In gtp_create_sockets(), gtp->sk_created is set to true before gtp->sk0 and gtp->sk1u are assigned. A concurrent GTP Echo Response packet on another CPU observes sk_created == true and dereferences the still-NULL gtp->sk0 in gtp0_handle_echo_resp(), causing a kernel panic.
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:gtp_encap_recv (drivers/net/gtp.c:542 gtp0_handle_echo_resp) Call Trace:
<IRQ> udp_queue_rcv_one_skb ip_protocol_deliver_rcu ip_local_deliver Kernel panic - not syncing: Fatal exception in interrupt
Reorder the assignments so that gtp->sk0 and gtp->sk1u are fully visible before gtp->sk_created is set to true. This ensures no concurrent packet path can observe the flag without valid socket pointers.
Fixes: b20dc3c68458 ("gtp: Allow to create GTP device without FDs") Reported-by: AutonomousCodeSecurity@microsoft.com Reported-by: Xiang Mei (Microsoft) xmei5@asu.edu Reported-by: Cen Zhang (Microsoft) blbllhy@gmail.com Signed-off-by: Cen Zhang (Microsoft) blbllhy@gmail.com
drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 9a12cc53da00..2b5a8f6d24d0 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1456,9 +1456,9 @@ static int gtp_create_sockets(struct gtp_dev *gtp, const struct nlattr *nla, return PTR_ERR(sk1u); }
- gtp->sk_created = true; gtp->sk0 = sk0; gtp->sk1u = sk1u;
- gtp->sk_created = true;
I don't believe that this is sufficient to address the problem described as there is no synchronisation between the reader and writer of sk_created.
I wonder if this might be addressed using smp_store_release/smp_load_acquire.
On Wed, Aug 19, 2026 at 01:48:20PM +0100, Simon Horman wrote:
I don't believe that this is sufficient to address the problem described as there is no synchronisation between the reader and writer of sk_created.
I wonder if this might be addressed using smp_store_release/smp_load_acquire.
Thanks. v2 uses smp_store_release()/smp_load_acquire() as suggested.
While reviewing all sk_created access points, we also found a teardown race in gtp_encap_disable() and a missing RTNL lock in gtp_genl_send_echo_req(). These are addressed in a new patch 2/2.
Regarding the Sashiko review: https://sashiko.dev/#/patchset/20260816035205.57966-1-blbllhy@gmail.com
Could a concurrent RX softirq checking gtp->sk_created without smp_load_acquire() still observe it as true while gtp->sk0 remains NULL?
Addressed in v2 patch 1/2.
Does the error path in gtp_create_sockets() properly synchronize with concurrent RX softirqs? Could this lead to a Use-After-Free?
Independent pre-existing issue.
Could the KASAN null pointer dereference actually be caused by the teardown path? Does this path need synchronization to wait for concurrent softirqs before clearing the pointers?
We reproduced this and addressed it with another teardown path issue in v2 patch 2/2.
Does modifying the RX SKB in place during an echo response corrupt data for concurrent readers (tcpdump)?
Independent pre-existing issue.
Cen
osmocom-net-gprs@lists.osmocom.org
-
Cen Zhang (Microsoft) -
Simon Horman