CVE-2026-68322 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
rds: Fix inet6_addr_lst NULL dereference when IPv6 is disabled
When booting with the 'ipv6.disable=1' parameter, inet6_addr_lst is never initialized because inet6_init() exits before addrconf_init() is called to initialize it. An attempt to bind an RDS socket to an ipv6 address results in a crash in __ipv6_chk_addr_and_flags()
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
RIP: 0010:__ipv6_chk_addr_and_flags+0x1df/0x7e0 Call Trace: <TASK> ipv6_chk_addr+0x3b/0x50 rds_tcp_laddr_check+0x155/0x3b0 [rds_tcp]
rds_trans_get_preferred+0x15d/0x2d0 [rds]
? trace_hardirqs_on+0x2d/0x110 rds_bind+0x1433/0x1d60 [rds]
? rds_remove_bound+0xd50/0xd50 [rds]
? aa_af_perm+0x250/0x250 ? __might_fault+0xde/0x190 ? __sys_bind+0x1dc/0x210 __sys_bind+0x1dc/0x210 ? __ia32_sys_socketpair+0x100/0x100 ? restore_fpregs_from_fpstate+0x53/0x100 __x64_sys_bind+0x73/0xb0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7f47f8269ea9 </TASK>
The following code reproduces the issue:
struct sockaddr_in6 addr; s = socket(PF_RDS, SOCK_SEQPACKET, 0);
memset(&addr, 0, sizeof(addr)); inet_pton(AF_INET6, ADDRESS, &addr.sin6_addr); addr.sin6_family = AF_INET6; addr.sin6_port = htons(PORT);
bind(s, &addr, sizeof(addr));
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability represents a critical null pointer dereference in the Linux kernel's RDS (Reliable Datagram Sockets) implementation when IPv6 is disabled through the kernel boot parameter ipv6.disable=1. The issue occurs due to improper initialization sequence during kernel boot where inet6_addr_lst remains uninitialized because inet6_init() exits prematurely before addrconf_init() can initialize it. When an application attempts to bind an RDS socket to an IPv6 address, the system crashes in the __ipv6_chk_addr_and_flags() function which tries to access the uninitialized inet6_addr_lst pointer.
The technical flaw stems from a fundamental race condition in kernel initialization logic where the IPv6 subsystem fails to properly initialize core data structures when the entire IPv6 stack is disabled. According to CWE-476, this represents a NULL pointer dereference vulnerability that occurs due to improper null checking and initialization sequences. The crash manifests through KASAN (Kernel Address Sanitizer) reporting a null pointer dereference in the memory range 0x0000000000000008-0x000000000000000f, specifically within the __ipv6_chk_addr_and_flags function which is part of the IPv6 address validation process.
The operational impact of this vulnerability is significant as it allows for a kernel crash that can result in system instability and potential denial of service conditions. Attackers who can control socket binding operations could potentially trigger this condition by attempting to bind RDS sockets to IPv6 addresses when IPv6 support is disabled, leading to complete system crashes or reboot cycles. This vulnerability affects systems running Linux kernels with the ipv6.disable=1 boot parameter and applications utilizing the RDS protocol that attempt IPv6 address binding operations.
The mitigation strategy involves ensuring proper initialization of IPv6 subsystem components regardless of the ipv6.disable setting, implementing null checks before accessing inet6_addr_lst, or modifying the RDS socket binding logic to properly handle cases where IPv6 functionality is disabled. From an ATT&CK perspective, this vulnerability could be categorized under T1499.004 (Endpoint Denial of Service) as it enables denial of service through kernel crashes. The fix typically requires patching the kernel initialization sequence to ensure inet6_addr_lst is properly handled even when IPv6 is disabled, or implementing defensive programming practices that check for null pointers before dereferencing. This vulnerability demonstrates the importance of proper initialization ordering and null pointer validation in kernel space operations, particularly when dealing with optional subsystems that may be disabled at runtime. The issue was discovered through systematic kernel testing using Syzkaller, highlighting the value of automated fuzzing tools in identifying subtle initialization race conditions in complex kernel codebases.