CVE-2026-99179: watch_queue: Fix note pool publication race in watch_queue_set_size()

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.