In the Linux kernel, the following vulnerability has been resolved:

audit: Fix data races of skbqueuelen() readers on audit_queue

Multiple readers access auditqueue.qlen via skbqueuelen() without holding the queue lock or using READONCE(), while kauditd writes to this field via the skb_dequeue() → __skbunlink() path with WRITEONCE() protected by a spinlock. This constitutes data races.

All affected skbqueuelen(&auditqueue) call sites: - kauditdthread() waiteventfreezable() condition - auditreceivemsg() AUDITGET handler (s.backlog assignment) - auditreceive() backlog check - auditlogstart() backlog check and pr_warn()

KCSAN reports the following conflicting access pattern (one example):

BUG: KCSAN: data-race in auditlogstart / skb_dequeue

write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57: skbdequeue+0x70/0xf0 kauditdsendqueue+0x71/0x220 kauditdthread+0x1cb/0x430 kthread+0x1c2/0x210 retfromfork+0x162/0x1a0 retfromfork_asm+0x1a/0x30

read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1: auditlogstart+0x2a0/0x6b0 auditcoredumps+0x64/0xa0 docoredump+0x14b/0x1260 getsignal+0xeb2/0xf70 archdosignalorrestart+0x41/0x170 exittousermodeloop+0xa2/0x1c0 dosyscall64+0x1a3/0x1c0 entrySYSCALL64afterhwframe+0x76/0xe0

value changed: 0x00000001 -> 0x00000000

Resolve the race by switching to lockless helper skbqueuelenlockless(), which internally uses READONCE() and properly pairs with the WRITE_ONCE() write accesses already present on the writer side.

[PM: line length tweak]