CVE-2024-35786

What it actually does

Incorrect error path in nouveau_gem_ioctl_pushbuf leaves the client mutex locked when VM_BIND is enabled and legacy submission is attempted, causing subsequent nouveau ioctls or nouveau_drm_postclose to deadlock on the still-held mutex.

Why it matters to the business

Systems using the nouveau driver with modern userspace that enables VM_BIND can experience GPU process hangs or kernel thread deadlocks, resulting in loss of display/GPU functionality and requiring reboots; prevalence in Linux distributions using nouveau makes broad fleet impact possible.

How an attack unfolds

An attacker with access to a process that can open the nouveau device and issue GEM pushbuf ioctls triggers the buggy error path when VM_BIND is active; the resulting locked mutex then blocks any later nouveau operation in the same or other processes, producing a denial-of-service deadlock without further attacker interaction.

How to fix it

Upgrade the Linux kernel to a version containing commit c288a61a48ddb77ec097e11ab81b81027cd4e197 or later; rebuild and reboot all affected systems; where immediate patching is impossible, restrict unprivileged access to the nouveau device nodes via device ACLs or disable the nouveau driver if an alternative GPU driver is available.

How to confirm the fix worked

Confirm the running kernel contains commit c288a61a48ddb77ec097e11ab81b81027cd4e197 or a backport; attempt to reproduce the original ioctl sequence under VM_BIND and verify no mutex deadlock occurs; review nouveau driver source for the corrected error-path unlock.

Typical attack path

1. Obtain access to a user session that can open /dev/dri/renderD* or equivalent nouveau device node
2. Enable or ensure VM_BIND is active for the client context
3. Issue a legacy GEM pushbuf ioctl that the driver now rejects
4. Trigger any subsequent nouveau ioctl or process exit that attempts to acquire the still-locked mutex
5. Observe kernel or userspace thread deadlock

How to detect it

Search kernel logs and dmesg for nouveau mutex-related warnings or stalls around GEM pushbuf or postclose paths; inspect process traces showing threads blocked inside nouveau ioctls; correlate with userspace processes that open nouveau devices while VM_BIND is enabled.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems using nouveau
• Apply device-node access restrictions until patches are deployed
• Monitor for nouveau-related kernel hangs in production workloads
• Review downstream distribution kernels for the backported fix