CVE-2026-99179

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

watch queue: Fix note pool publication race in watch queue set size()

There is a race between watch queue set size() and post one notification(). watch queue set size() publishes wqueue->notes, notes bitmap, nr pages and nr notes with plain stores, and post one notification() reads them with plain loads under a different lock, so nothing orders the four stores against the poster's loads: depending on the build, notes can be stored last (gcc 14 on x86-64 does this). Since keyctl watch key() lets a watch attach to a queue before it is sized, post one notification() can already be running on another CPU at that moment: it reads nr notes > 0, passes its bounds check, and then reads notes while it is still NULL, dereferencing notes[0].

An unprivileged user triggers this reliably by watching one of its own keys through a notification pipe and racing ioctl(IOC WATCH QUEUE SET SIZE) on that pipe against keyctl(KEYCTL SETPERM) on the key from another CPU, triggering:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post one notification.isra.0+0xa2/0x1e0 Call Trace: post watch notification+0x148/0x180 keyctl setperm key+0x119/0x130 do syscall 64+0x108/0x4c0 entry SYSCALL 64 after hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt

Fix this by publishing nr notes last with smp store release(), and by reading it once with smp load acquire() in post one notification() before the bitmap and the page array are touched. A poster that observes a non-zero nr notes then also observes the pool behind it; one that observes zero drops the notification as before.