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@xxxxxxxxx

> 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