CVE-2026-43164 in Linux
Summary
by MITRE • 05/06/2026
In the Linux kernel, the following vulnerability has been resolved:
udplite: Fix null-ptr-deref in __udp_enqueue_schedule_skb().
syzbot reported null-ptr-deref of udp_sk(sk)->udp_prod_queue. [0]
Since the cited commit, udp_lib_init_sock() can fail, as can udp_init_sock() and udpv6_init_sock().
Let's handle the error in udplite_sk_init() and udplitev6_sk_init().
[0]:
BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:82 [inline]
BUG: KASAN: null-ptr-deref in atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
BUG: KASAN: null-ptr-deref in __udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 Read of size 4 at addr 0000000000000008 by task syz.2.18/2944
CPU: 1 UID: 0 PID: 2944 Comm: syz.2.18 Not tainted syzkaller #0 PREEMPTLAZY Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <IRQ> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 kasan_report+0xa2/0xe0 mm/kasan/report.c:595 check_region_inline mm/kasan/generic.c:-1 [inline]
kasan_check_range+0x264/0x2c0 mm/kasan/generic.c:200 instrument_atomic_read include/linux/instrumented.h:82 [inline]
atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]
__udp_enqueue_schedule_skb+0x151/0x1480 net/ipv4/udp.c:1719 __udpv6_queue_rcv_skb net/ipv6/udp.c:795 [inline]
udpv6_queue_rcv_one_skb+0xa2e/0x1ad0 net/ipv6/udp.c:906 udp6_unicast_rcv_skb+0x227/0x380 net/ipv6/udp.c:1064 ip6_protocol_deliver_rcu+0xe17/0x1540 net/ipv6/ip6_input.c:438 ip6_input_finish+0x191/0x350 net/ipv6/ip6_input.c:489 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 ip6_input+0x16c/0x2b0 net/ipv6/ip6_input.c:500 NF_HOOK+0x354/0x3f0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6149 [inline]
__netif_receive_skb+0xd3/0x370 net/core/dev.c:6262 process_backlog+0x4d6/0x1160 net/core/dev.c:6614 __napi_poll+0xae/0x320 net/core/dev.c:7678 napi_poll net/core/dev.c:7741 [inline]
net_rx_action+0x60d/0xdc0 net/core/dev.c:7893 handle_softirqs+0x209/0x8d0 kernel/softirq.c:622 do_softirq+0x52/0x90 kernel/softirq.c:523 </IRQ> <TASK> __local_bh_enable_ip+0xe7/0x120 kernel/softirq.c:450 local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:924 [inline]
__dev_queue_xmit+0x109c/0x2dc0 net/core/dev.c:4856 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline]
ip6_finish_output+0x158/0x4e0 net/ipv6/ip6_output.c:219 NF_HOOK_COND include/linux/netfilter.h:307 [inline]
ip6_output+0x342/0x580 net/ipv6/ip6_output.c:246 ip6_send_skb+0x1d7/0x3c0 net/ipv6/ip6_output.c:1984 udp_v6_send_skb+0x9a5/0x1770 net/ipv6/udp.c:1442 udp_v6_push_pending_frames+0xa2/0x140 net/ipv6/udp.c:1469 udpv6_sendmsg+0xfe0/0x2830 net/ipv6/udp.c:1759 sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg+0xe5/0x270 net/socket.c:742 __sys_sendto+0x3eb/0x580 net/socket.c:2206 __do_sys_sendto net/socket.c:2213 [inline]
__se_sys_sendto net/socket.c:2209 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2209 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xd2/0xf20 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f67b4d9c629 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f67b5c98028 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f67b5015fa0 RCX: 00007f67b4d9c629 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f67b4e32b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000040000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f67b5016038 R14: 00007f67b5015fa0 R15: 00007ffe3cb66dd8 </TASK>
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/17/2026
The vulnerability described involves a null pointer dereference in the Linux kernel's UDP Lite implementation, specifically within the `__udp_enqueue_schedule_skb()` function. This flaw occurs when the `udp_sk(sk)->udp_prod_queue` field is accessed without proper validation, leading to a kernel panic or potential privilege escalation. The issue was identified by syzbot, an automated fuzzer, which reported a KASAN (Kernel Address Sanitizer) error indicating a null pointer dereference at address 0x0000000000000008. The stack trace reveals that the error originates from `__udp_enqueue_schedule_skb()` in `net/ipv4/udp.c` at line 1719, where the code attempts to read from `udp_sk(sk)->udp_prod_queue` without ensuring that the pointer is valid. This type of vulnerability falls under CWE-476, Null Pointer Dereference, and aligns with ATT&CK technique T1068, Exploitation for Privilege Escalation, when exploited in kernel contexts.
The root cause lies in the socket initialization process where `udp_lib_init_sock()`, `udp_init_sock()`, and `udpv6_init_sock()` functions can fail, yet the `udplite_sk_init()` and `udplitev6_sk_init()` functions do not properly handle these error conditions. When these initialization functions return an error, the `udp_prod_queue` field remains uninitialized, resulting in a null pointer access when subsequently used. The call path shows the error propagates from UDP socket operations through network input processing, ultimately reaching a point where the uninitialized pointer is dereferenced during packet queueing. This demonstrates a classic case of error handling failure in kernel subsystems, where an error condition in a lower-level function is not propagated upward, leading to undefined behavior in higher-level functions that assume proper initialization.
The operational impact of this vulnerability is significant as it can lead to system crashes or denial of service conditions in kernel space. An attacker could potentially exploit this by sending crafted UDP packets to trigger the error path, causing a system reboot or making the network stack unavailable. The vulnerability affects systems running kernel versions where the problematic commit was introduced, particularly those using UDP Lite protocols, which are less common but still present in certain network stacks. The flaw represents a critical security risk because it operates in kernel mode and can potentially be leveraged for privilege escalation if combined with other vulnerabilities, as indicated by the ATT&CK framework's mapping to privilege escalation techniques.
Mitigation strategies include applying the kernel patch that properly handles the error conditions in socket initialization functions. The fix requires modifying `udplite_sk_init()` and `udplitev6_sk_init()` to check for initialization failures and return appropriate error codes when `udp_lib_init_sock()`, `udp_init_sock()`, or `udpv6_init_sock()` fail. Additionally, system administrators should ensure that all kernel updates are applied promptly, especially those addressing memory safety vulnerabilities. Monitoring for unusual system crashes or network disruptions can help detect exploitation attempts. The fix should be validated through kernel testing and regression analysis to ensure that proper error handling does not introduce performance issues or break existing functionality. Systems using UDP Lite protocols should be prioritized for patching, as they are directly affected by this vulnerability, and regular kernel security audits should be conducted to identify similar error handling gaps in other network subsystems.