CVE-2026-99179 in Linux
Summary
by MITRE • 10/28/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel watch_queue subsystem contains a critical race condition vulnerability within the interaction between size configuration and notification posting mechanisms, specifically involving the functions watch_queue_set_size() and post_one_notification(). This flaw arises from improper memory ordering when publishing data structures that describe the state of the note pool. The core technical issue is that watch_queue_set_size() updates several fields including wqueue->notes, notes_bitmap, nr_pages, and nr_notes using plain store instructions which do not enforce any specific ordering constraints relative to subsequent loads by other CPUs. Conversely, post_one_notification() reads these same variables under a different lock but also utilizes plain load operations. This lack of explicit synchronization means that the compiler or CPU may reorder these memory accesses in ways that violate logical consistency. For instance, on x86-64 systems compiled with GCC 14, there is a risk that nr_notes might be stored last among the four variables. Consequently, another processor executing post_one_notification() can observe a non-zero value for nr_notes while wqueue->notes remains NULL because the store to notes has not yet been made visible or ordered correctly relative to the read of nr_notes.
The operational impact of this vulnerability is severe, leading to kernel crashes and potential denial of service conditions. An unprivileged user can reliably trigger this race condition by attaching a watch to one of their own keys via a notification pipe and then simultaneously racing an ioctl call to set the queue size against a keyctl system call that modifies key permissions from another CPU core. When the race is successfully exploited, post_one_notification() passes its bounds check because it sees nr_notes greater than zero but subsequently attempts to dereference notes[0] while the pointer is still null. This results in a kernel NULL pointer dereference with address 0x0000000000000000. The resulting fatal exception triggers an immediate kernel panic, halting system operation and causing a complete denial of service for all processes running on that machine.
From a classification perspective, this vulnerability aligns closely with CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (Race Condition). Specifically, it represents a failure to properly order memory operations in a multi-threaded or multiprocessor environment, leading to the observation of inconsistent state. In terms of the MITRE ATT&CK framework for Linux systems, this flaw could be leveraged within techniques related to Denial of Service via kernel exploitation, although its primary classification remains a concurrency bug rather than an intentional attack vector by external adversaries unless exploited for privilege escalation in more complex scenarios involving further memory corruption primitives not present here.
The resolution involves implementing proper atomic operations and memory barriers to ensure correct publication semantics. The fix modifies watch_queue_set_size() to publish the nr_notes field last using smp_store_release(), which acts as a release barrier ensuring that all prior writes, including those to notes, bitmap, and pages, are visible to other CPUs before this flag is updated. Simultaneously, post_one_notification() is adjusted to read nr_notes once using smp_load_acquire(), which serves as an acquire barrier guaranteeing that subsequent reads of the note pool data structures will see the values written prior to the release store. This ensures that if a poster observes a non-zero value for nr_notes, it is guaranteed to also observe the fully initialized and valid note pool behind it. If zero is observed, the notification is dropped as intended, maintaining system stability without requiring complex locking changes beyond these specific atomic operations.