In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers… (CVE-2026-64435)
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]
AI Analysis
Technical Summary
The Linux kernel audit subsystem had a data race condition involving concurrent access to the audit_queue length field via skb_queue_len(). Multiple readers accessed this field without holding the queue lock or using READ_ONCE(), while the writer updated it with WRITE_ONCE() protected by a spinlock. This mismatch caused data races detected by KCSAN. The race was fixed by switching to skb_queue_len_lockless(), which uses READ_ONCE() internally, ensuring proper synchronization with existing WRITE_ONCE() writes.
Potential Impact
Data races can lead to inconsistent or corrupted audit queue length values, potentially causing incorrect audit behavior or kernel instability. However, no known exploits are reported in the wild. The impact is primarily on kernel reliability and correctness in audit message handling.
Mitigation Recommendations
A fix is available that replaces unsafe queue length accesses with a lockless helper using proper memory access primitives. Users should update to a Linux kernel version that includes this fix. Since this is a kernel-level issue, applying the official kernel patch or upgrading to a fixed kernel version is the recommended remediation.
In the Linux kernel, the following vulnerability has been resolved: audit: Fix data races of skb_queue_len() readers on audit_queue Multiple readers… (CVE-2026-64435)
Description
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]
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel audit subsystem had a data race condition involving concurrent access to the audit_queue length field via skb_queue_len(). Multiple readers accessed this field without holding the queue lock or using READ_ONCE(), while the writer updated it with WRITE_ONCE() protected by a spinlock. This mismatch caused data races detected by KCSAN. The race was fixed by switching to skb_queue_len_lockless(), which uses READ_ONCE() internally, ensuring proper synchronization with existing WRITE_ONCE() writes.
Potential Impact
Data races can lead to inconsistent or corrupted audit queue length values, potentially causing incorrect audit behavior or kernel instability. However, no known exploits are reported in the wild. The impact is primarily on kernel reliability and correctness in audit message handling.
Mitigation Recommendations
A fix is available that replaces unsafe queue length accesses with a lockless helper using proper memory access primitives. Users should update to a Linux kernel version that includes this fix. Since this is a kernel-level issue, applying the official kernel patch or upgrading to a fixed kernel version is the recommended remediation.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-h4f8-j958-689c
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64435"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a6542099c2644c7f80835e1
Added to database: 07/25/2026, 23:08:57 UTC
Last enriched: 07/25/2026, 23:23:41 UTC
Last updated: 09/07/2026, 10:52:10 UTC
Views: 42
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.