CVE-2026-43381

What it actually does

This flaw affects the Linux kernel nouveau DRM driver. When the NVIDIA GPU managed by nouveau is runtime-suspended, a local userspace process can access DisplayPort AUX interfaces exposed as /dev/drm_dp_* and trigger an invalid interaction with the nouveau GSP code path. Instead of returning a busy status for the sleeping device, vulnerable kernels may hit a kernel warning/crash path in r535_gsp_msgq_wait, causing loss of availability. The impact is local denial of service; the CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, no confidentiality impact, no integrity impact, and high availability impact.

Why it matters to the business

Systems using the Linux kernel nouveau driver for NVIDIA GPUs may become unstable or crash when local software interacts with DisplayPort AUX device interfaces while the GPU is suspended. In practice, this can interrupt workstations, laptops, kiosks, GPU-enabled Linux endpoints, or maintenance workflows such as firmware update checks. The vulnerability is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and requires local access, so broad internet-scale risk is low; however, affected endpoints can still experience operational disruption if an untrusted or compromised local account can trigger the crash.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel with the nouveau driver loaded and a compatible NVIDIA GPU using the affected GSP-related path. The attacker waits for or causes the GPU to enter runtime suspend, then invokes a userspace action that opens or interacts with /dev/drm_dp_* DisplayPort AUX device nodes. Vulnerable kernels may attempt an AUX transfer while the device is asleep and proceed into nouveau GSP message queue handling rather than returning EBUSY. This can trigger a kernel warning or crash in r535_gsp_msgq_wait, resulting in denial of service. Benign tools such as firmware update utilities may also accidentally exercise this path, so observed crashes are not necessarily malicious.

How to fix it

Upgrade to a Linux kernel build that includes the nouveau/dpcd fix returning EBUSY for DisplayPort AUX transfers when the device is runtime-suspended. No exact upstream or distribution-specific fixed versions were provided in the input, so use vendor advisories from the relevant Linux distribution or kernel provider to identify the first patched kernel. Prioritize systems with NVIDIA GPUs using the nouveau driver and where untrusted local users can run code. If immediate patching is not possible, reduce exposure by restricting access to /dev/drm_dp_* device nodes, limiting local interactive access, disabling or blacklisting the nouveau driver where operationally acceptable, using a vendor-supported alternative driver if appropriate, or adjusting power-management behavior to avoid the vulnerable suspended-device state until patched. Treat mitigations as temporary because driver access controls and power settings may vary by distribution and workload.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build containing the nouveau DisplayPort AUX runtime-suspend fix. Validate with package manager metadata, distribution security advisories, kernel changelogs, or source-level confirmation of the change that returns EBUSY when the device is asleep. On affected test hardware, verify that interacting with /dev/drm_dp_* while the GPU is runtime-suspended no longer produces kernel warnings, nouveau GSP errors, oopses, hangs, or reboots. Check that the nouveau module version corresponds to the patched kernel and that the host has actually rebooted into the fixed kernel, not merely installed it. Also review device permissions for /dev/drm_dp_* to ensure they are not unnecessarily accessible to untrusted users.

Typical attack path

1. Obtain local shell or ability to run code as a low-privileged user on a Linux system using the nouveau driver.
2. Confirm that /dev/drm_dp_* device nodes are present and accessible to the user or to a process the attacker can influence.
3. Wait for the NVIDIA GPU to enter runtime suspend or induce conditions where the device is asleep.
4. Open or interact with the DisplayPort AUX interface exposed through /dev/drm_dp_* while the device is suspended.
5. Trigger the vulnerable nouveau GSP code path, causing a kernel warning, driver failure, hang, or system crash.
6. Use the resulting outage as a local denial-of-service condition.

How to detect it

Look for evidence of prior exploitation or accidental triggering in kernel logs and system journals. Relevant sources include dmesg output, journald/kernel logs, /var/log/kern.log, /var/log/messages, crash dumps, pstore records, kdump/vmcore data, auditd logs for access to /dev/drm_dp_* if enabled, and process execution logs for utilities that interact with firmware or DisplayPort AUX devices. Search for nouveau warnings or crashes containing r535_gsp_msgq_wait, GSP message queue failures, DisplayPort AUX transfer errors, runtime suspend messages, and kernel call traces associated with processes such as fwupd. Because the vulnerability causes denial of service rather than a unique persistence artifact, there may be no durable IOC beyond crash evidence and local device access. Correlate timestamps of kernel warnings or reboots with local logins, process starts, and device-node access to distinguish malicious triggering from benign firmware update or hardware-management activity.

• r535_gsp_msgq_wait
• drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164
• WARNING: CPU:
• [nouveau]
• Comm: fwupd
• /dev/drm_dp_
• drm_dp
• nouveau/dpcd
• GSP
• runtime suspended
• device is asleep
• aux xfer
• AUX transfer
• EBUSY
• kernel: WARNING: CPU
• kernel: .*nouveau.*r535_gsp_msgq_wait
• kernel: .*drm_dp
• kernel: .*GSP.*msgq

What your security team should do

• Inventory Linux systems with NVIDIA GPUs using the nouveau driver and prioritize those with multi-user access or untrusted local workloads.
• Track distribution kernel advisories and deploy the first kernel update that includes the nouveau/dpcd runtime-suspend AUX transfer fix.
• Reboot systems after kernel updates and verify they are running the patched kernel version.
• Temporarily restrict access to /dev/drm_dp_* device nodes on systems that cannot be patched quickly.
• Monitor kernel logs for nouveau GSP warnings, r535_gsp_msgq_wait traces, GPU runtime-suspend errors, and crashes involving fwupd or other utilities accessing DisplayPort AUX interfaces.
• Do not treat this as an internet-exposed remote code execution issue; prioritize based on local access risk and operational availability requirements.
• If repeated crashes are observed, preserve kernel logs and correlate them with local user sessions, firmware update activity, and access to DRM DisplayPort device nodes.