CVE-2026-99179

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: Fix note pool publication race in watch_queue_set_size()<br /> <br /> There is a race between watch_queue_set_size() and post_one_notification().<br /> watch_queue_set_size() publishes wqueue-&gt;notes, notes_bitmap, nr_pages and<br /> nr_notes with plain stores, and post_one_notification() reads them with<br /> plain loads under a different lock, so nothing orders the four stores<br /> against the poster&amp;#39;s loads: depending on the build, notes can be stored<br /> last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch<br /> attach to a queue before it is sized, post_one_notification() can already<br /> be running on another CPU at that moment: it reads nr_notes &gt; 0, passes<br /> its bounds check, and then reads notes while it is still NULL,<br /> dereferencing notes[0].<br /> <br /> An unprivileged user triggers this reliably by watching one of its own<br /> keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE)<br /> on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU,<br /> triggering:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0<br /> Call Trace:<br /> __post_watch_notification+0x148/0x180<br /> keyctl_setperm_key+0x119/0x130<br /> do_syscall_64+0x108/0x4c0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix this by publishing nr_notes last with smp_store_release(), and by<br /> reading it once with smp_load_acquire() in post_one_notification() before<br /> the bitmap and the page array are touched. A poster that observes a<br /> non-zero nr_notes then also observes the pool behind it; one that observes<br /> zero drops the notification as before.