Description

In the Linux kernel, the following vulnerability has been resolved: vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive(). udp_tunnel_sock_release() could set sk->sk_user_data to NULL while vxlan_gro_prepare_receive() is running. Let's check if rcu_dereference_sk_user_data() is NULL after skb_gro_remcsum_init().

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-15T06:22:42.633Z",
  "pubdate": "2026-08-15T06:22:42.633Z",
  "executiveSummary": "A null pointer dereference vulnerability exists in the Linux kernel's VXLAN subsystem, specifically within the vxlan_gro_prepare_receive() function.\nThe vulnerability arises due to a race condition between socket release operations and Generic Receive Offload (GRO) packet processing.\nSpecifically, udp_tunnel_sock_release() can set the socket user data pointer sk->sk_user_data to NULL concurrently while vxlan_gro_prepare_receive() is actively executing and accessing this data.\nIf successfully triggered, this memory safety flaw results in a kernel null pointer dereference, leading to a kernel crash and subsequent denial of service (DoS) of the affected system.\nThe affected product is the Linux kernel utilizing VXLAN tunneling and UDP socket tunnels.\nExploitation requires the ability to send network traffic that triggers VXLAN GRO packet processing simultaneously with socket teardown events, implying local or remote network traffic injection capabilities depending on the kernel's network exposure.",
  "technicalDetails": "The vulnerability resides in the network subsystem of the Linux kernel, specifically impacting the VXLAN tunneling protocol handler and UDP tunnel socket management functions.\nThe vulnerable component is identified as the vxlan_gro_prepare_receive() function, which processes incoming packets during Generic Receive Offload operations.\nThe root cause of the vulnerability is a concurrency race condition involving socket lifecycle management. During the execution of vxlan_gro_prepare_receive(), the function interacts with socket user data attached to the underlying UDP socket.\nHowever, the asynchronous execution of udp_tunnel_sock_release() can set the socket user data pointer (sk->sk_user_data) to NULL while the GRO reception preparation routine is still running.\nPrior to the implemented fix, vxlan_gro_prepare_receive() did not adequately validate that the pointer returned by rcu_dereference_sk_user_data() remained valid after intermediate operations such as skb_gro_remcsum_init().\nThe step-by-step attack flow involves: (1) An incoming VXLAN packet hits the network stack, initiating GRO receive preparation via vxlan_gro_prepare_receive(); (2) Concurrently, a socket teardown or release operation invokes udp_tunnel_sock_release(); (3) The socket user data pointer sk->sk_user_data is set to NULL mid-execution; (4) The execution flow in vxlan_gro_prepare_receive() attempts to dereference the now-NULL pointer, triggering a kernel panic due to a null pointer dereference.\nThe impact of this vulnerability is localized to a kernel panic causing a denial of service (DoS). There are no specific authentication or privilege requirements to trigger network packet processing, although timing the race condition accurately requires specific network traffic patterns or multi-threaded operations interacting with socket closures."
}