CVE-2026-43164: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-43164 Overview

CVE-2026-43164 is a null pointer dereference vulnerability in the Linux kernel's UDP-Lite (udplite) protocol implementation. The flaw exists in __udp_enqueue_schedule_skb() within net/ipv4/udp.c and was reported by the syzbot fuzzer. The issue arises because udp_lib_init_sock() can fail after a prior commit changed its return semantics, and the failure path was not propagated through udplite_sk_init() and udplitev6_sk_init(). When the socket initialization partially fails, udp_sk(sk)->udp_prod_queue remains unset, leading to a null pointer dereference when packets are processed.

Critical Impact

A local attacker can trigger a kernel null pointer dereference via crafted UDP-Lite socket operations, resulting in kernel panic and denial of service.

Affected Products

• Linux kernel (mainline) with UDP-Lite support enabled
• Stable kernel branches prior to commits 0f13fa08, 470c7ca2, and f27030ac
• Distributions shipping vulnerable kernels with CONFIG_IP_UDPLITE enabled

Discovery Timeline

• 2026-05-06 - CVE-2026-43164 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43164

Vulnerability Analysis

The vulnerability resides in the UDP-Lite socket initialization path. After a prior refactor, udp_lib_init_sock() gained the ability to return errors, and by extension udp_init_sock() and udpv6_init_sock() can also fail. The UDP-Lite wrappers udplite_sk_init() and udplitev6_sk_init() ignored these return codes, leaving sockets in a partially initialized state.

The specific casualty is udp_sk(sk)->udp_prod_queue, which remains uninitialized when allocation fails upstream. When traffic later arrives on the socket, __udp_enqueue_schedule_skb() at net/ipv4/udp.c:1719 performs an atomic_read() against this null pointer.

KASAN flagged the access as a null-ptr-deref of size 4 at address 0x0000000000000008. The crash is reachable from the IPv6 receive path through udpv6_queue_rcv_one_skb() and __udpv6_queue_rcv_skb(). This is a kernel-side null pointer dereference [CWE-476] resulting in denial of service.

Root Cause

The root cause is unchecked error propagation. When the cited commit changed udp_lib_init_sock() to allow failures, the UDP-Lite init wrappers were not updated to handle the new failure mode. A successful call to sk_alloc() followed by a failed protocol-specific init left the socket usable for receive paths despite missing critical state.

Attack Vector

A local unprivileged user can create a UDP-Lite socket and force conditions that cause udp_lib_init_sock() to fail, then send or receive traffic on the socket to trigger the dereference. The syzbot reproducer used sendto() against an IPv6 UDP-Lite socket. Because the dereference occurs in softirq context during packet processing, the result is a kernel panic affecting the entire host.

No verified public exploit code is available beyond the syzbot reproducer referenced in the kernel commit messages. See the kernel commit 0f13fa08 for the patch and reproducer details.

Detection Methods for CVE-2026-43164

Indicators of Compromise

• Kernel oops or panic messages referencing __udp_enqueue_schedule_skb and null-ptr-deref in dmesg or /var/log/kern.log
• KASAN reports identifying reads at low addresses (near 0x8) within net/ipv4/udp.c
• Unexpected host reboots or soft lockups correlated with UDP-Lite socket usage by unprivileged processes

Detection Strategies

• Audit running kernel versions across the fleet and compare against patched stable releases containing commits 0f13fa08, 470c7ca2, and f27030ac
• Monitor for processes creating sockets with protocol IPPROTO_UDPLITE (protocol 136) where this is not expected by the workload
• Inspect crash dumps and kdump artifacts for stack traces involving udplite_sk_init, udplitev6_sk_init, or __udp_enqueue_schedule_skb

Monitoring Recommendations

• Forward kernel logs and KASAN output to a centralized log platform for correlation across hosts
• Alert on repeated kernel panics or crashes on the same host within short time windows, indicating possible exploitation attempts
• Track socket() syscalls with SOCK_DGRAM and protocol IPPROTO_UDPLITE via auditd or eBPF-based telemetry

How to Mitigate CVE-2026-43164

Immediate Actions Required

• Apply the upstream Linux kernel patches referenced in commits 0f13fa08, 470c7ca2, and f27030ac as soon as your distribution publishes updated packages
• If patching is not immediately feasible, disable UDP-Lite by blacklisting the udplite module on systems that do not require it
• Restrict the ability of untrusted local users to create raw or atypical sockets where operationally acceptable

Patch Information

The fix updates udplite_sk_init() and udplitev6_sk_init() to check the return value of udp_init_sock() and udpv6_init_sock() and propagate errors instead of silently continuing. The relevant patches are available at kernel commit 0f13fa08, kernel commit 470c7ca2, and kernel commit f27030ac.

Workarounds

• Blacklist the udplite kernel module via /etc/modprobe.d/ to prevent loading on systems that do not use the protocol
• Use seccomp or LSM policies to deny socket(AF_INET, SOCK_DGRAM, IPPROTO_UDPLITE) and the IPv6 equivalent for untrusted workloads
• Apply network namespace isolation and capability restrictions to limit which workloads can create UDP-Lite sockets

# Configuration example: blacklist the udplite module
echo 'blacklist udplite' | sudo tee /etc/modprobe.d/blacklist-udplite.conf
echo 'install udplite /bin/true' | sudo tee -a /etc/modprobe.d/blacklist-udplite.conf
sudo rmmod udplite 2>/dev/null || true