CVE-2026-31550

What it actually does

This is a local denial-of-service flaw in the Linux kernel power-domain driver for Broadcom BCM2835/BCM2711-class platforms. The bcm2835_asb_control() routine used too short a polling timeout while waiting for the AXI-to-Switch-Bridge handshake to complete for the V3D graphics block. Under intensive workloads, especially around runtime power-management suspend/resume of V3D, the bridge acknowledgement can arrive later than expected. The failed handshake can leave the V3D power domain in an inconsistent or broken state, causing later hardware accesses to trigger bus faults or hang the system. The vulnerability does not provide confidentiality or integrity impact and requires local access, but it can cause high availability impact on affected systems.

Why it matters to the business

Affected Linux systems using the impacted Broadcom graphics/power-management path can become unstable or hang when local workloads exercise the V3D graphics block and runtime power management. In operational terms, this can interrupt edge devices, embedded systems, Raspberry Pi-class deployments, build/test rigs, kiosks, or appliance-style Linux systems that depend on continuous availability. The CVSS score indicates moderate severity, EPSS is very low and stable, there is no known CISA KEV listing, no known ransomware association, and no public exploit maturity reported, so urgency is primarily driven by whether affected hardware is used in availability-sensitive roles.

How an attack unfolds

An attacker must already have local ability to run code or submit workloads on an affected Linux system. They would attempt to create repeated or intensive V3D/GPU activity and power-management transitions so that the kernel driver enters the vulnerable bcm2835_asb_control() path during runtime suspend. If the ASB acknowledgement is not observed within the original very short timeout, the driver logs a failure such as inability to disable the ASB master for V3D. The failed power-off can leave the graphics block in a bad state. Subsequent accesses to that hardware can then cause bus faults, kernel errors, or a full system hang, resulting in denial of service. Exploitation is expected to be reliability-dependent and platform-specific rather than a remote, general-purpose attack.

How to fix it

Update the Linux kernel to a version that includes the bcm2835-power driver fix increasing the ASB control polling timeout from 1 microsecond to 5 microseconds and replacing the ad hoc polling loop with readl_poll_timeout_atomic(). No exact fixed kernel versions were provided in the input, so use the security advisories and changelogs from the Linux distribution, device vendor, or kernel source tree for the affected platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, disabling or limiting GPU/V3D use where operationally acceptable, and avoiding configurations that aggressively cycle runtime power management for the affected graphics block. For embedded or appliance deployments, validate vendor firmware/kernel images rather than assuming the upstream fix is present.

How to confirm the fix worked

Confirm the running kernel package or build includes the bcm2835-power change for bcm2835_asb_control() that increases the polling timeout to 5 microseconds. On source-based or custom kernels, inspect the driver implementation for use of readl_poll_timeout_atomic() in the ASB control path and verify the timeout is no longer the vulnerable 1 microsecond value. On packaged systems, confirm the installed kernel version matches the distribution or device-vendor advisory containing the fix. After remediation, run representative V3D/GPU workloads with runtime power management enabled and monitor dmesg, journalctl, and kernel logs for recurrence of V3D ASB disable failures, bus faults, or hangs. Absence of the known error under stress testing is supportive, but version/build verification should be treated as the authoritative validation method.

Typical attack path

1. Obtain local code execution or an account capable of running workloads on an affected Linux system.
2. Determine that the system uses the Broadcom BCM2835/BCM2711 V3D graphics/power-domain driver path.
3. Generate repeated or intensive V3D/GPU activity that causes runtime power-management suspend and resume transitions.
4. Trigger the vulnerable ASB control polling path during a V3D power-domain transition.
5. Cause the ASB handshake to exceed the insufficient timeout, producing a failed V3D ASB disable operation.
6. Rely on the inconsistent V3D power state to produce later bus faults, kernel instability, or a system hang.

How to detect it

To determine whether this condition has already been triggered, review kernel-oriented logs rather than application logs. Useful sources include dmesg output, systemd journal kernel facility entries, /var/log/kern.log, /var/log/messages, crash dumps, watchdog reset logs, and platform management logs where available. Search for the specific V3D ASB failure message, Broadcom power-domain errors, bus fault reports, GPU/V3D runtime power-management failures, and unexplained hangs or watchdog resets occurring during graphics-heavy or hardware-accelerated workloads. Correlate timestamps with local user sessions, scheduled jobs, container workloads, graphical applications, video processing, browser acceleration, test harnesses, or any process repeatedly exercising the V3D device. Because the same symptom can occur accidentally under intensive workloads, logs alone may not prove malicious exploitation; look for repeated triggering by an untrusted user or workload, recurrence before patching, and disappearance after applying the fixed kernel.

• Failed to disable ASB master for v3d
• bcm2835_asb_control
• bcm2835-power
• v3d
• ASB master for v3d
• runtime PM suspend
• bus fault
• readl_poll_timeout_atomic
• drivers/pmdomain/bcm/bcm2835-power.c

What your security team should do

• Prioritize patching on availability-sensitive Linux systems using Broadcom BCM2835/BCM2711-class hardware or Raspberry Pi-class platforms with V3D enabled.
• Inventory embedded, edge, kiosk, lab, and appliance Linux deployments to identify systems running affected kernels on the relevant hardware.
• Use vendor or distribution kernel advisories to identify the fixed package level because no exact fixed versions were provided.
• Restrict local access and untrusted workload execution on affected systems until patched.
• Monitor kernel logs for V3D ASB disable failures, bus faults, GPU-related runtime PM errors, and unexpected hangs or reboots.
• For custom kernels, backport the specific bcm2835-power driver change and test V3D runtime suspend/resume behavior under load.
• Treat suspected events as denial-of-service incidents unless additional evidence indicates separate compromise, because this flaw by itself does not imply data theft or privilege escalation.