[PATCH net] gtp: fix NULL pointer dereference in gtp0_handle_echo_resp()

[PATCH net] gtp: fix NULL pointer dereference in gtp0_handle_echo_resp()

[Cen Zhang (Microsoft)]

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;
 }
-- 
2.52.0

Re: [PATCH net] gtp: fix NULL pointer dereference in gtp0_handle_echo_resp()

[Simon Horman]

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.

-- 
pw-bot: changes-requested

Re: [PATCH net] gtp: fix NULL pointer dereference in gtp0_handle_echo_resp()

[Cen Zhang (Microsoft)]

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