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.