CVE-2022-50405
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-18

Last updated on: 2025-12-11

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: net/tunnel: wait until all sk_user_data reader finish before releasing the sock There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-18
Last Modified
2025-12-11
Generated
2026-05-27
AI Q&A
2025-09-18
EPSS Evaluated
2026-05-25
NVD
CVE-2022-50405
Affected Vendors & Products
Showing 8 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 3.18 (inc) to 4.9.337 (exc)
linux linux_kernel From 4.10 (inc) to 4.14.303 (exc)
linux linux_kernel From 4.15 (inc) to 4.19.270 (exc)
linux linux_kernel From 4.20 (inc) to 5.4.229 (exc)
linux linux_kernel From 5.5 (inc) to 5.10.163 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.86 (exc)
linux linux_kernel From 5.16 (inc) to 6.0.16 (exc)
linux linux_kernel From 6.1 (inc) to 6.1.2 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a race condition in the Linux kernel's vxlan network tunnel implementation. When deleting a vxlan device while it is receiving packets, the socket (sock) may be released prematurely after being accessed via sk_user_data. This can lead to a NULL pointer dereference in functions like vxlan_ecn_decapsulate() and vxlan_get_sk_family(), causing kernel crashes or oops errors. The issue arises because the code does not wait for all readers of sk_user_data to finish before releasing the socket.


How can this vulnerability impact me? :

This vulnerability can cause system instability or crashes due to NULL pointer dereferences in the kernel when vxlan devices are deleted during packet reception. This can lead to kernel oops or panic, potentially causing denial of service or requiring system reboots, impacting availability and reliability of systems using vxlan tunnels.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, update the Linux kernel to a version where the fix is applied. The fix involves waiting for all sk_user_data readers to finish before releasing the socket, preventing the race condition. Avoid deleting vxlan devices during active packet reception until the kernel is patched.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart