---
id: "CVE-2026-99179"
kind: "vulnerability"
aliases: ["CVE-2026-99179"]
title: "Linux kernel: watch queue race lets unprivileged user crash the system"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["linux-kernel", "multi-user-hosts", "runtime", "self-hosted"]
not_affected_if: ["no-untrusted-local-users", "patched-kernel"]
published_at: "2026-10-28T11:17:38+00:00"
first_seen_at: "2026-10-28T11:32:36+00:00"
updated_at: "2026-10-28T11:35:25+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99179", "first_seen_at": "2026-10-28T11:32:36+00:00"}]
---

# Linux kernel: watch queue race lets unprivileged user crash the system

A race between setting a watch queue's size and posting a notification leaves the note pool pointer NULL while the kernel dereferences it. An unprivileged local user can trigger a kernel NULL pointer dereference and panic the machine.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel builds listed in the upstream stable advisories (unknown from these sources)
- Check whether the kernel includes the commit that publishes `nr_notes` with `smp_store_release()` in `watch_queue_set_size()` (unknown from these sources)

## Fix

- Update the Linux kernel to a stable release that includes the watch_queue note pool publication fix (exact versions unknown from these sources)
- Until patched, restrict local unprivileged use of keyctl watch and notification pipes where feasible (unknown from these sources)

## Timeline

- 2026-10-28T11:32:36+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99179

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_