PT-2026-64656 · Linux · Linux
CVE-2026-64435
·
Published
2026-07-25
·
Updated
2026-07-25
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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]
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux