{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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-\u003enotes, 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 \u003e 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.",
  "id": "DEBIAN-CVE-2026-99179",
  "modified": "2026-10-29T05:47:30.938885812Z",
  "published": "2026-10-28T11:17:38.633Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-99179"
    }
  ],
  "upstream": [
    "CVE-2026-99179"
  ]
}