CVE-2026-98623

What it actually does

Out-of-bounds read in nvkm_clk_ustate_update when list_for_each_entry exits without a match: the loop cursor is left pointing at the list head (cast to struct nvkm_pstate) and subsequently dereferenced, reachable by writing an arbitrary or nonexistent pstate ID into the 'pstate' debugfs file.

Why it matters to the business

On systems exposing Nouveau debugfs, an unprivileged local user can trigger kernel memory reads outside expected bounds, risking crashes, denial of service, or limited information disclosure; the issue is five days old with negligible exploit probability and no known campaigns.

How an attack unfolds

An attacker with write access to the Nouveau 'pstate' debugfs entry supplies an ID absent from clk->states (or any ID when the perf list is empty); the function skips the break path, treats the list head as a valid pstate, and performs the pstate->pstate != req comparison, producing an invalid memory access.

How to fix it

Apply the upstream fix that replaces the bare list cursor with an explicit 'found' flag; rebuild and deploy the patched kernel; if the fix is unavailable, restrict debugfs access via mount options or file permissions until the update can be installed.

How to confirm the fix worked

Confirm the presence of the 'found' variable and early break logic inside nvkm_clk_ustate_update in the running kernel source; attempt to reproduce the original condition by writing an invalid ID to the pstate debugfs file while monitoring for oops or slab warnings.

Typical attack path

1. Locate and open /sys/kernel/debug/dri/.../pstate (or equivalent Nouveau debugfs file)
2. Write a nonexistent or out-of-range pstate identifier to the file
3. Kernel executes nvkm_clk_ustate_update with the attacker-supplied value
4. list_for_each_entry completes without matching, leaving cursor at list head
5. Subsequent pointer dereference reads outside allocated structures

How to detect it

Monitor kernel logs for oops or BUG entries referencing nvkm_clk_ustate_update or list cursor dereference near drm/nouveau; audit access attempts to the pstate debugfs file; inspect any user-space processes writing numeric IDs to Nouveau debugfs entries.

• nvkm_clk_ustate_update
• pstate->pstate != req
• /sys/kernel/debug/dri/.*/pstate
• list_for_each_entry.*clk->states

What your security team should do

• Patch kernels within the next maintenance window given the five-day publication window
• Temporarily restrict Nouveau debugfs exposure on multi-tenant or untrusted systems
• Add the function name and debugfs path to existing kernel integrity monitoring
• Re-evaluate after 30 days if EPSS remains flat and no exploitation reports appear