CVE-2026-46006

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the Nouveau DRM graphics driver. The driver validates a relocation offset using 32-bit arithmetic: adding 4 to a user-controlled 32-bit offset can wrap around before being compared with the backing buffer object size. A local user who can access the Nouveau DRM device can submit a crafted push buffer that bypasses the intended bounds check, potentially causing out-of-bounds kernel memory access. Depending on allocator state and exploit reliability, impact may include local privilege escalation, kernel crash, information disclosure, or arbitrary kernel memory corruption.

Why it matters to the business

Systems using the Nouveau open-source NVIDIA driver may allow a local authenticated user to compromise the host, disrupt availability, or gain elevated privileges. This is most relevant for Linux workstations, shared GPU systems, lab machines, VDI hosts, and multi-user servers where untrusted users can access DRM devices. The issue is not listed in CISA KEV, is not known to be used in ransomware, has very low EPSS, and has no public exploit maturity reported, so internet-scale exploitation is unlikely; however, the CVSS impact is high because successful exploitation can affect confidentiality, integrity, and availability of the local system.

How an attack unfolds

An attacker first obtains local code execution as a low-privileged user on a Linux system where the Nouveau kernel module is present and accessible through DRM device nodes. The attacker opens a DRM device and submits a Nouveau GEM push buffer containing relocation metadata with an offset value near the 32-bit integer boundary. Because the vulnerable bounds check performs the addition in 32-bit arithmetic, the offset plus 4 can wrap to a small value and pass validation. The driver then applies the relocation using the original invalid offset, causing memory access outside the expected buffer object. A failed attempt may produce a GPU fault, process failure, or kernel crash; a successful attempt may corrupt kernel memory in a controlled way and allow privilege escalation or other kernel-level compromise.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the Nouveau fix for the relocation bounds check, specifically the change that performs the offset-plus-size validation using 64-bit arithmetic. If an updated kernel is not immediately available, reduce exposure by disabling the Nouveau driver where it is not required, blacklisting the nouveau module, using a vendor-supported alternative graphics driver where appropriate, and restricting access to DRM device nodes to trusted users only. On shared or multi-user systems, review membership in groups that grant GPU device access, commonly video or render, and remove unnecessary access. Reboot after kernel update or module changes so the fixed kernel and driver are active.

How to confirm the fix worked

Confirm the running kernel package includes the vendor backport or upstream patch for the Nouveau push-buffer relocation overflow. Validate that the active running kernel is the updated version, not only that the package is installed. On source-based or custom kernels, inspect the Nouveau relocation validation path and confirm the calculation is performed in 64-bit arithmetic before comparison with the buffer size. Check whether the nouveau module is loaded; if mitigation relies on disabling it, confirm it is not loaded after reboot and that module blacklist configuration is effective. Verify permissions on DRM device nodes and group membership for users who can access GPU devices. Where possible, run vendor-provided regression or kernel validation tests for DRM/Nouveau after patching to ensure graphics functionality remains stable.

Typical attack path

1. Gain local access to a Linux host as an unprivileged user.
2. Confirm the Nouveau DRM driver is loaded and that the user can access DRM device nodes such as GPU card or render devices.
3. Open the Nouveau DRM interface and prepare a crafted GEM push buffer submission.
4. Set relocation metadata so the relocation buffer offset overflows during the 32-bit bounds check.
5. Submit the malicious push buffer through the DRM ioctl path.
6. Trigger out-of-bounds memory access when the kernel applies the relocation.
7. Use the resulting memory corruption to crash the system, disclose data, or attempt local privilege escalation.

How to detect it

There are no reliable, unique indicators that prove exploitation of this vulnerability, and successful local kernel memory corruption may leave few artifacts. Detection should focus on exposure plus suspicious local activity. Review kernel logs, system journal, audit logs, and EDR telemetry for crashes or faults involving the Nouveau DRM driver, GPU resets, kernel oops messages, or abnormal activity around DRM device access. Useful sources include journalctl, dmesg, /var/log/kern.log, /var/log/messages, auditd syscall/device-access logs, EDR process telemetry, and Linux authentication logs. Look for low-privileged users or unexpected processes opening DRM card or render device nodes and issuing a high volume of DRM/Nouveau ioctls shortly before a kernel crash, GPU reset, privilege change, or suspicious root shell. Correlate events involving nouveau, DRM, GEM push buffers, compositor failures, Xorg/Wayland instability, and sudden reboots. Also review recent changes to video/render group membership and local accounts on systems where Nouveau is loaded.

• nouveau_gem_pushbuf_reloc_apply
• DRM_IOCTL_NOUVEAU_GEM_PUSHBUF
• nouveau
• /dev/dri/card
• /dev/dri/renderD
• GPU fault
• kernel BUG
• kernel NULL pointer dereference
• general protection fault
• Oops
• Xid
• drm:nouveau

What your security team should do

• Prioritize patching Linux systems that load the Nouveau driver and allow local users, developers, students, contractors, containers, or batch jobs to access GPU/DRM devices.
• Inventory systems with the nouveau kernel module loaded and identify which users or service accounts can access DRM device nodes.
• If immediate patching is not possible, disable or blacklist Nouveau on systems that do not require it, and restrict video/render group membership to trusted users.
• Give higher urgency to shared workstations, VDI fleets, GPU lab systems, and multi-user compute environments because the vulnerability requires only local low-privileged access.
• Monitor for kernel crashes, GPU faults, and unusual DRM ioctl activity on unpatched systems, recognizing that successful exploitation may leave limited forensic evidence.
• Track Linux distribution advisories for fixed kernel package versions because no exact fixed versions were provided in the input.
• After remediation, reboot affected systems and verify they are actually running the fixed kernel.