CVE-2024-46763 in Linux
Summary
by MITRE • 09/18/2024
In the Linux kernel, the following vulnerability has been resolved:
fou: Fix null-ptr-deref in GRO.
We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0]
The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou.
When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period.
So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL.
Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers.
[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]
Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou]
udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]
ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]
napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)
do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated---
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 04/06/2026
The vulnerability CVE-2024-46763 addresses a null pointer dereference in the Linux kernel's Foo Over UDP (FOU) Generic Receive Offload (GRO) mechanism. This flaw manifests during the shutdown of a host system when network namespaces are dismantled or tunnels are explicitly torn down. The root cause lies in the improper handling of socket user data references within the FOU subsystem, specifically within the fou_gro_receive() function. During normal operation, the udp_tunnel_sock_release() function sets sk->sk_user_data to NULL as part of the socket cleanup process, which occurs after a single RCU grace period. However, in-flight UDP GRO receive operations may still attempt to access this socket, leading to a null pointer dereference when the FOU GRO handler tries to read sk->sk_user_data at offset 8, which corresponds to the protocol field in the FOU structure.
The technical execution of this vulnerability involves a race condition between socket destruction and in-flight packet processing. When a network namespace is shut down or a tunnel is explicitly torn down, the kernel's network stack initiates the release of associated resources. The udp_tunnel_sock_release() function is responsible for cleaning up the socket by setting its user data pointer to NULL, but this cleanup does not immediately invalidate all references to the socket. Subsequently, if a UDP GRO receive operation occurs, the kernel's network stack may still find the socket and invoke the FOU GRO handler, which attempts to dereference the sk->sk_user_data pointer without proper null checks. This condition results in a kernel NULL pointer dereference at address 0x0000000000000008, triggering a kernel oops and potentially leading to system instability or a denial of service.
The operational impact of CVE-2024-46763 extends beyond simple system crashes, as it represents a critical race condition that can be exploited to cause system instability or denial of service in environments heavily utilizing FOU tunnels or network namespaces. The vulnerability is particularly concerning in cloud and virtualized environments where network namespaces are frequently created and destroyed, such as Amazon EC2 instances where this issue was observed. The attack vector is relatively straightforward, requiring only the triggering of network namespace teardown or explicit tunnel shutdown operations, which can occur during normal system maintenance, application deployment, or system shutdown procedures. This vulnerability aligns with CWE-476, which describes NULL pointer dereference conditions, and can be mapped to ATT&CK technique T1499.004, which covers network denial of service attacks through resource exhaustion or system instability.
The fix for CVE-2024-46763 involves implementing proper null pointer checks in the FOU GRO handlers and using the rcu_dereference_sk_user_data() function to safely access socket user data. The kernel developers modified the fou_from_sock() function to use the RCU-safe dereference mechanism and added explicit NULL checks within the FOU GRO handlers to prevent access to potentially freed socket structures. This approach ensures that even if an in-flight packet processing operation attempts to access a socket that has been partially cleaned up, the kernel will not attempt to dereference a NULL pointer. The solution follows established kernel security practices for handling concurrent access to shared data structures and aligns with the Linux kernel's recommended approaches for dealing with RCU-protected data. The fix is minimal and targeted, addressing only the specific race condition without altering the broader FOU functionality, thus maintaining system compatibility while eliminating the vulnerability. This remediation strategy is consistent with the kernel's approach to handling similar race conditions in network subsystems and reflects the importance of proper synchronization mechanisms when dealing with shared kernel resources in multi-threaded environments.