CVE-2026-43485

What it actually does

This is a local denial-of-service issue in the Linux kernel nouveau graphics driver, specifically in GSP-related ACPI probe paths. The vulnerable code can hit WARN_ON conditions during ACPI probing. On systems configured to treat kernel warnings as fatal, such as with panic_on_warn enabled, triggering the warning can cause a kernel panic and system crash. Even where warnings are not fatal, repeated triggering can create noisy kernel logs and operational instability around the affected graphics driver path. The CVSS vector indicates local access is required, attack complexity is low, and the primary impact is availability rather than confidentiality or integrity.

Why it matters to the business

Successful exploitation can crash affected Linux systems that use the nouveau driver, causing service interruption, workstation disruption, or loss of availability for workloads running on impacted hosts. The risk is highest on systems with NVIDIA hardware using nouveau and with kernel hardening or debugging settings that panic on warnings. EPSS is currently very low, it is not listed in CISA KEV, and no mature public exploit is indicated, so broad active exploitation is unlikely; however, systems where local users or untrusted workloads can interact with the affected driver should still be prioritized because the failure mode is a full host outage.

How an attack unfolds

An attacker first needs local access to an affected Linux system, typically as an authenticated low-privileged user or through a workload already running on the host. The attacker then attempts to exercise the nouveau driver code path that performs GSP-related ACPI probing, for example by causing driver initialization, device probing, GPU power-management transitions, module reload activity, or other interactions that reach the vulnerable ACPI probe logic. On vulnerable kernels, the probe path may hit a WARN_ON condition. If the system is configured with panic_on_warn enabled, that warning is converted into a kernel panic, immediately crashing the host. If panic_on_warn is not enabled, exploitation is less severe and may primarily produce repeated kernel warning messages rather than a hard denial of service.

How to fix it

Apply a vendor-provided Linux kernel update that includes the nouveau/gsp change removing the problematic WARN_ON checks from ACPI probe handling. No exact fixed package versions were provided in the input, so use the fixed kernel version supplied by the Linux distribution, appliance vendor, cloud image provider, or kernel maintainers for the affected product line. Where immediate patching is not possible, reduce exposure by disabling panic_on_warn unless it is explicitly required, restricting local shell access to trusted users, preventing untrusted workloads from interacting with GPU devices, and disabling or blacklisting the nouveau driver on systems where it is not required. If the host can use a supported alternative graphics driver or does not need local GPU functionality, consider disabling nouveau as a temporary mitigation after validating operational impact.

How to confirm the fix worked

Confirm remediation by checking that the running kernel version is at or above the vendor-fixed build and that the installed kernel package changelog or advisory includes the nouveau/gsp ACPI WARN_ON fix. Reboot into the patched kernel and verify with uname -a and the distribution package manager that the active kernel is the updated one, not merely installed alongside an older kernel. Review /proc/cmdline and sysctl settings to determine whether panic_on_warn is enabled. Validate exposure by checking whether the nouveau module is loaded using lsmod, whether NVIDIA hardware is present using lspci, and whether kernel logs contain nouveau/GSP ACPI warning traces. If nouveau is not loaded and cannot be auto-loaded by local users, practical exposure is reduced.

Typical attack path

1. Gain local access to an affected Linux system with the nouveau kernel driver available or loaded.
2. Confirm the system exposes NVIDIA hardware or nouveau/GSP-related driver paths that can be exercised from local context.
3. Trigger driver activity that reaches the GSP ACPI probe path, such as device probing, power-state transitions, or module/driver reinitialization where permissions allow.
4. Cause the vulnerable WARN_ON condition to fire in the kernel.
5. If panic_on_warn is enabled, the kernel panics and the host becomes unavailable until rebooted or recovered.

How to detect it

To determine whether this issue was already triggered, review host-level kernel logs and boot history rather than application logs. Relevant sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, systemd reboot records, and hardware or hypervisor event logs showing unexpected resets. Look for kernel warning traces involving nouveau, GSP, ACPI probing, WARN_ON, followed by Oops, kernel panic, or abrupt reboot events. Correlate these events with local user logins, sudo activity, module load/unload attempts, GPU device access, changes to /proc/sys/kernel/panic_on_warn, and invocations of tools such as modprobe, rmmod, udevadm, lspci, or GPU-management scripts. Because the issue is not known to have distinctive public exploit tooling, detection should focus on suspicious local activity immediately preceding nouveau-related WARN_ON messages or kernel panics.

• nouveau
• gsp
• ACPI
• WARN_ON
• kernel: WARNING:
• kernel: ------------[ cut here ]------------
• kernel panic
• Kernel panic - not syncing
• panic_on_warn
• /proc/sys/kernel/panic_on_warn
• /sys/module/nouveau
• modprobe nouveau
• rmmod nouveau
• journalctl -k
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash
• vmcore

What your security team should do

• Prioritize patching Linux systems that use the nouveau driver on NVIDIA hardware, especially multi-user systems, developer workstations, GPU-enabled servers, and hosts running untrusted local workloads.
• Identify systems with panic_on_warn enabled because they are most likely to experience a full system crash if the warning is triggered.
• Deploy the vendor-fixed kernel and reboot into it; confirm the active running kernel is patched, not just installed.
• Where patching is delayed, disable or blacklist nouveau if it is not operationally required, or restrict access to GPU device nodes and driver-management operations.
• Monitor kernel logs for nouveau, GSP, ACPI, WARN_ON, Oops, and panic events to identify attempted triggering or instability.
• Treat this as an availability risk rather than a data-theft vulnerability; focus response planning on outage prevention, rapid reboot/recovery, and kernel lifecycle management.