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]