The kernel's nouveau memory management has a counter‑mismanagement bug. When a large compound folio belonging to device‑private memory is split into smaller sub‑folios, the code that updates the allocation counter mistakenly does not insert the new sub‑folio into the counter. After the split each sub‑folio is freed individually, making the counter go below zero and wrap around the unsigned integer limit. This makes the kernel believe that fewer allocations exist than actually do, preventing the associated memory chunk from being reclaimed and causing a persistent memory leak. The counter underflow also triggers a warning but does not recover, leaving the memory permanently allocated.

The issue exists in the Linux kernel source, affecting all distributions that ship either the upstream kernel or a derivative with the nouveau graphics driver enabled. The vendor information simply lists Linux:Linux, and no specific kernel version ranges are provided in the data; therefore any kernel where this code path is active and the bug has not been patched is affected. The related commit references point to a patch that has been merged, suggesting that kernels newer than that commit are fixed.

Because the bug is a kernel memory‑management defect with no clearly defined exploitation vector, it is classified as a local denial‑of‑service risk: a user or process that can allocate large device‑private memory blobs via the nouveau driver could trigger the counter underflow and cause the kernel to leak memory. Security scores are not provided, and the EPSS data is not available; the vulnerability is also not listed in the CISA KEV catalog. However, once the flaw is introduced the system may run into reduced memory availability and potentially trigger a kernel OOM killer or become unresponsive. The risk is thus significant for affected systems running the vulnerable kernel.