CVE-2026-64435 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
audit: Fix data races of skb_queue_len() readers on audit_queue
Multiple readers access audit_queue.qlen via skb_queue_len() without holding the queue lock or using READ_ONCE(), while kauditd writes to this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE() protected by a spinlock. This constitutes data races.
All affected skb_queue_len(&audit_queue) call sites: - kauditd_thread() wait_event_freezable() condition - audit_receive_msg() AUDIT_GET handler (s.backlog assignment) - audit_receive() backlog check - audit_log_start() backlog check and pr_warn()
KCSAN reports the following conflicting access pattern (one example): ================================================================== BUG: KCSAN: data-race in audit_log_start / skb_dequeue
write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skb_dequeue+0x70/0xf0 kauditd_send_queue+0x71/0x220 kauditd_thread+0x1cb/0x430 kthread+0x1c2/0x210 ret_from_fork+0x162/0x1a0 ret_from_fork_asm+0x1a/0x30
read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: audit_log_start+0x2a0/0x6b0 audit_core_dumps+0x64/0xa0 do_coredump+0x14b/0x1260 get_signal+0xeb2/0xf70 arch_do_signal_or_restart+0x41/0x170 exit_to_user_mode_loop+0xa2/0x1c0 do_syscall_64+0x1a3/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0xe0
value changed: 0x00000001 -> 0x00000000 ==================================================================
Resolve the race by switching to lockless helper skb_queue_len_lockless(), which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side.
[PM: line length tweak]
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability described represents a critical data race condition within the Linux kernel's audit subsystem, specifically affecting the audit_queue data structure management. This issue manifests when multiple concurrent threads attempt to access the queue length field without proper synchronization mechanisms, creating a scenario where read operations can observe inconsistent or partially updated values during write operations.
The technical flaw stems from improper synchronization between reader and writer threads accessing the audit_queue.qlen field through skb_queue_len() function calls while kauditd performs write operations via skb_dequeue() and __skb_unlink() paths that are protected by spinlocks but use WRITE_ONCE() for memory ordering. The readers lack proper memory barriers or atomic access patterns, allowing them to observe data races that can lead to unpredictable behavior and potential system instability.
Multiple code locations within the kernel audit subsystem were identified as vulnerable, including kauditd_thread() wait conditions, audit_receive_msg() handler operations, and various backlog checking mechanisms in audit_receive() and audit_log_start() functions. These call sites demonstrate a systemic issue where concurrent access patterns were not properly coordinated through appropriate locking or atomic primitives.
The KCSAN (Kernel Concurrency Sanitizer) report clearly demonstrates the conflicting access pattern where one thread performs a write operation to the queue length field while another reads from it, resulting in inconsistent values being observed. The specific example shows a write operation modifying the value from 0x00000001 to 0x00000000 during a concurrent read operation by a different thread, creating a scenario where audit subsystem operations may fail or produce incorrect results.
This vulnerability aligns with CWE-362, which describes a race condition in concurrent execution environments where multiple threads access shared resources without proper synchronization. The issue also relates to ATT&CK technique T1059.003 for privilege escalation through kernel-level manipulation and T1547.001 for system service manipulation that could occur during exploitation attempts.
The resolution involves implementing a lockless helper function skb_queue_len_lockless() that internally utilizes READ_ONCE() operations to properly pair with existing WRITE_ONCE() writes on the writer side. This approach eliminates the race condition by ensuring all readers use appropriate atomic memory access patterns while maintaining performance characteristics of the original implementation, effectively addressing the data consistency issues without introducing significant overhead or blocking behavior.
The fix directly addresses the root cause by ensuring proper memory ordering semantics between concurrent readers and writers, preventing situations where audit subsystem operations could observe corrupted queue state information that might compromise system security monitoring capabilities or lead to denial of service conditions through improper backlog handling.