CVE-2026-99179

What it actually does

Race condition in watch_queue_set_size() and post_one_notification() where plain stores to wqueue->notes, notes_bitmap, nr_pages and nr_notes are not ordered against plain loads under a separate lock, allowing post_one_notification() to observe nr_notes > 0 while notes remains NULL and dereference notes[0].

Why it matters to the business

Unprivileged local users can trigger a kernel NULL pointer dereference leading to immediate panic and full system crash on Linux hosts, disrupting all workloads and services until reboot.

How an attack unfolds

An attacker creates a notification pipe, attaches a watch to one of their own keys via keyctl_watch_key(), then concurrently issues IOC_WATCH_QUEUE_SET_SIZE on the pipe from one CPU while performing KEYCTL_SETPERM on the key from another CPU; the missing memory ordering lets the notification path read a stale nr_notes value and dereference a still-NULL notes array.

How to fix it

Apply the upstream fix that publishes nr_notes last via smp_store_release() and reads it once via smp_load_acquire() in post_one_notification(); rebuild and reboot onto the patched kernel.

How to confirm the fix worked

Verify the smp_store_release/smp_load_acquire change is present in watch_queue.c, confirm the race window is closed by code inspection, and test that concurrent watch attachment plus size setting no longer produces NULL dereferences.

Typical attack path

1. Create a watch_queue pipe and call keyctl_watch_key() to attach it to a key before sizing.
2. From a second thread or CPU, race ioctl(IOC_WATCH_QUEUE_SET_SIZE) against keyctl(KEYCTL_SETPERM) on the watched key.
3. post_one_notification() reads nr_notes > 0, passes bounds check, then dereferences the still-NULL notes pointer.
4. Kernel oops in post_one_notification triggers panic.

How to detect it

Search kernel logs and crash dumps for the exact BUG line 'kernel NULL pointer dereference' together with the call trace containing post_one_notification, __post_watch_notification, and keyctl_setperm_key; correlate with processes issuing watch_queue ioctls and keyctl syscalls around the same timestamp.

• 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
• watch_queue_set_size

What your security team should do

• Patch and reboot all Linux systems within the next maintenance window given the one-day publication age and reliable unprivileged trigger.
• Add kernel oops monitoring for post_one_notification NULL dereferences to detect attempted exploitation.
• Restrict unprivileged keyctl and watch_queue usage via SELinux/AppArmor or seccomp where workloads permit.