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