CVE-2026-64435

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: Fix data races of skb_queue_len() readers on audit_queue<br /> <br /> Multiple readers access audit_queue.qlen via skb_queue_len() without<br /> holding the queue lock or using READ_ONCE(), while kauditd writes to<br /> this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE()<br /> protected by a spinlock. This constitutes data races.<br /> <br /> All affected skb_queue_len(&amp;audit_queue) call sites:<br /> - kauditd_thread() wait_event_freezable() condition<br /> - audit_receive_msg() AUDIT_GET handler (s.backlog assignment)<br /> - audit_receive() backlog check<br /> - audit_log_start() backlog check and pr_warn()<br /> <br /> KCSAN reports the following conflicting access pattern (one example):<br /> ==================================================================<br /> BUG: KCSAN: data-race in audit_log_start / skb_dequeue<br /> <br /> write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57:<br /> skb_dequeue+0x70/0xf0<br /> kauditd_send_queue+0x71/0x220<br /> kauditd_thread+0x1cb/0x430<br /> kthread+0x1c2/0x210<br /> ret_from_fork+0x162/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1:<br /> audit_log_start+0x2a0/0x6b0<br /> audit_core_dumps+0x64/0xa0<br /> do_coredump+0x14b/0x1260<br /> get_signal+0xeb2/0xf70<br /> arch_do_signal_or_restart+0x41/0x170<br /> exit_to_user_mode_loop+0xa2/0x1c0<br /> do_syscall_64+0x1a3/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0xe0<br /> <br /> value changed: 0x00000001 -&gt; 0x00000000<br /> ==================================================================<br /> <br /> Resolve the race by switching to lockless helper skb_queue_len_lockless(),<br /> which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE()<br /> write accesses already present on the writer side.<br /> <br /> [PM: line length tweak]