CVE-2026-43072

What it actually does

This is a local Linux kernel denial-of-service issue in the VC4 DRM graphics driver. The vulnerable code incorrectly handles the return value from platform_get_irq_byname(): when IRQ lookup fails, the function returns a negative error code, but that value may be passed onward to devm_request_threaded_irq() instead of being rejected. In affected configurations, especially systems using the VC4 graphics driver, this can lead to improper IRQ registration behavior and kernel instability or crash conditions. The assessed impact is availability-only: no direct confidentiality or integrity impact is indicated by the CVSS vector.

Why it matters to the business

Successful exploitation can crash or destabilize affected Linux systems, causing service interruption, device reboot, or loss of availability. The issue is local and requires low-privileged access, so internet-wide remote exploitation is not expected, and the low EPSS score with no known exploited status suggests limited near-term exploitation likelihood. It is most relevant for Linux deployments using the VC4 graphics stack, such as Raspberry Pi-class systems or embedded Linux devices where graphics/display availability is operationally important.

How an attack unfolds

An attacker first needs local access to an affected Linux system with the vulnerable VC4 DRM driver present and reachable. From that position, they attempt to trigger a code path where the driver requests an IRQ by name and platform_get_irq_byname() fails, returning a negative error value. Because the vulnerable implementation does not correctly stop on that error, the invalid value can be propagated into threaded IRQ registration. Depending on kernel configuration, device state, and driver initialization path, this may result in a kernel warning, oops, panic, or device instability, producing a denial of service. There is no indication that this vulnerability enables privilege escalation, data theft, or remote code execution.

How to fix it

Update the Linux kernel to a vendor-provided version that includes the VC4 DRM fix for checking negative return values from platform_get_irq_byname() before requesting the threaded IRQ. No exact fixed package versions were provided, so administrators should consult the relevant Linux distribution, device vendor, or kernel stable advisory for the patched kernel release. Where immediate patching is not possible, reduce exposure by disabling or avoiding use of the VC4 DRM driver on systems that do not require it, restricting local shell access, limiting untrusted users, and applying standard hardening controls that reduce the ability of local users to interact with graphics or device-management interfaces.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the upstream or vendor backport for the VC4 DRM IRQ error-handling fix. Check the installed and booted kernel version with standard package and runtime tools, then compare it against the distribution or vendor advisory. On source-based or custom kernels, inspect the VC4 DRM driver code path to ensure negative return values from platform_get_irq_byname() are explicitly checked and handled before calling devm_request_threaded_irq(). Also confirm whether the vc4 driver is loaded using lsmod or equivalent tooling; systems that do not load or use the VC4 DRM driver are materially less exposed.

Typical attack path

1. Obtain local low-privileged access to an affected Linux system.
2. Confirm or infer that the system uses the VC4 DRM graphics driver.
3. Trigger driver initialization, probing, device binding, or another code path that causes IRQ lookup by name to fail.
4. Cause the negative IRQ lookup result to be passed into IRQ registration due to missing error handling.
5. Induce kernel instability, crash, or loss of system availability.

How to detect it

To determine whether this issue may have been exploited or triggered, review kernel and system logs for VC4 DRM driver errors, IRQ lookup or registration failures, kernel oops reports, panics, watchdog resets, and unexpected reboots. Relevant sources include journalctl kernel logs, dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps captured by kdump, and persistent pstore/ramoops records on embedded devices. Because no public exploit maturity, KEV listing, named threat actors, or ransomware use is reported, detection should focus on evidence of local denial-of-service activity rather than network indicators. Correlate crashes with local user sessions, device binding or module load events, graphics stack restarts, and recent changes to device tree or platform configuration that could cause IRQ lookup failure.

• vc4
• platform_get_irq_byname
• devm_request_threaded_irq
• Failed to request IRQ
• failed to request irq
• IRQ index
• irq: no irq domain found
• drm/vc4
• vc4-drm
• kernel panic
• Kernel panic
• Oops:
• BUG: kernel NULL pointer dereference
• watchdog: BUG: soft lockup
• watchdog: hard LOCKUP
• pstore
• ramoops
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /sys/module/vc4

What your security team should do

• Prioritize patching affected Linux systems that use VC4 graphics, especially embedded, kiosk, edge, or Raspberry Pi-class devices where local denial of service would disrupt operations.
• Track vendor kernel advisories and deploy the first available stable or distribution kernel containing the VC4 DRM fix.
• Inventory systems where the vc4 DRM driver is present or loaded, and scope remediation to those assets first.
• Restrict local interactive access to systems that cannot be patched promptly.
• If VC4 graphics support is not required, consider disabling the driver or removing it from custom kernel builds as a compensating control.
• Monitor kernel logs for IRQ registration errors, vc4 driver probe failures, oops messages, panics, or unexpected reboots on affected platforms.
• Treat this as a medium-severity local availability issue rather than a remote compromise indicator unless accompanied by other suspicious activity.