UBUNTU-CVE-2026-99179: Null Pointer Dereference
In the Linux kernel, the following vulnerability has been resolved: watchqueue: Fix note pool publication race in watchqueuesetsize() There is a race between watchqueuesetsize() and postonenotification(). watchqueuesetsize() publishes wqueue->notes, notesbitmap, nrpages and nrnotes with plain stores, and postonenotification() 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 keyctlwatchkey() lets a watch attach to a queue before it is sized, postonenotification() can already be running on another CPU at that moment: it reads nrnotes > 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(IOCWATCHQUEUESETSIZE) on that pipe against keyctl(KEYCTLSETPERM) on the key from another CPU, triggering: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:postonenotification.isra.0+0xa2/0x1e0 Call Trace: postwatchnotification+0x148/0x180 keyctlsetpermkey+0x119/0x130 dosyscall64+0x108/0x4c0 entrySYSCALL64afterhwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt Fix this by publishing nrnotes last with smpstorerelease(), and by reading it once with smploadacquire() in postonenotification() before the bitmap and the page array are touched. A poster that observes a non-zero nrnotes then also observes the pool behind it; one that observes zero drops the notification as before.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the Linux kernel watch queue implementation, publish nr_notes last with smp_store_release() in watch_queue_set_size(), and read nr_notes once with smp_load_acquire() in post_one_notification() before accessing the bitmap and page array.
Event History
Frequently Asked Questions
Who can trigger this issue?
An unprivileged local user can trigger it by watching one of their own keys through a notification pipe. The issue requires the user to race queue sizing on that pipe with a permission change on the watched key from another CPU.
What is the likely impact of successful exploitation?
The race can cause the kernel to dereference a NULL notification-note pointer in post_one_notification(). The reported outcome is a kernel NULL pointer dereference and BUG, which can disrupt the affected system.
How can I recognize that this race has occurred?
Kernel logs may show a NULL pointer dereference at address 0 with RIP in post_one_notification.isra.0. The call trace can include __post_watch_notification.