CVE-2026-43229

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel Chips&Media Wave5 VPU media driver. During device removal or cleanup, the driver could power down hardware and disable runtime power management before unregistering video devices and stopping pending video operations. In polling mode, a high-resolution timer can still queue work to the VPU IRQ worker thread, which then attempts to read hardware registers after the device is powered off. That invalid hardware access can trigger a synchronous external abort and cause a kernel panic, resulting in full system crash and loss of availability. The issue requires local access with the ability to exercise affected VPU/video encoding paths or trigger the relevant device lifecycle conditions; it does not provide confidentiality or integrity impact.

Why it matters to the business

Systems using affected Linux kernels with the Wave5 VPU driver enabled may experience unexpected crashes during video encoding or related media operations. For embedded, appliance, edge, media-processing, or industrial systems that rely on this hardware acceleration path, exploitation or accidental triggering can cause service interruption, device reboot, failed jobs, degraded customer experience, and operational downtime. The EPSS score is very low and no known exploited status is reported, so broad internet-scale exploitation is unlikely; however, availability-sensitive platforms using the affected driver should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker with local access first determines that the target system is running an affected Linux kernel and has the Chips&Media Wave5 VPU driver present and active. The attacker then exercises video encoding or media device operations that cause the Wave5 driver to enter polling mode and use its hrtimer-driven worker path. By timing or repeatedly triggering device removal, cleanup, suspend/autosuspend, or power-management transitions while video devices remain registered, the attacker can create a race where the worker thread continues to run after runtime PM has powered down the hardware. The worker thread then calls the Wave5 register read routine against powered-off hardware, causing a bus error or synchronous external abort. The kernel treats the fatal exception as a panic, crashing the system and denying service until reboot or recovery.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the Wave5 driver cleanup order. The fix unregisters video devices earlier in the driver remove path so active video operations are stopped before worker threads are cleaned up and before runtime power management can power down the hardware. If an updated kernel package is not yet available from the distribution or device vendor, apply the relevant upstream stable kernel patch once backported. As interim mitigations, disable or unload the Wave5 VPU driver where it is not required, restrict local access to video device nodes, avoid exposing media encoding capabilities to untrusted local users or containers, and consider disabling affected hardware acceleration paths on availability-critical systems until patched. Because no exact fixed package versions were provided, administrators should rely on their OS, appliance, or BSP vendor advisories for the corrected kernel build.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that includes the Wave5 VPU cleanup-order fix. Review package changelogs, kernel source patches, or vendor advisories for references to the Chips&Media Wave5 driver, video device unregistration order, runtime PM cleanup, or prevention of register access after power-down. On running systems, verify the active kernel version with standard inventory tooling and compare it to the vendor-fixed release. Where safe and appropriate, perform controlled regression testing of Wave5-backed video encoding while repeatedly starting, stopping, suspending, or removing the media device; patched systems should not panic and should not log synchronous external aborts from wave5_vdi_read_register or wave5_vpu_irq_work_fn. Also validate that untrusted users and workloads do not have unnecessary access to relevant /dev/video* devices.

Typical attack path

1. Obtain local user-level access to a system running an affected Linux kernel with the Wave5 VPU media driver enabled.
2. Confirm the Wave5 driver or related video device nodes are present and usable.
3. Start or repeatedly trigger video encoding/media operations that exercise the Wave5 VPU polling path.
4. Induce or wait for runtime power-management, autosuspend, driver cleanup, or device removal conditions while video operations are still registered.
5. Cause the hrtimer to queue VPU IRQ worker activity after hardware power-down.
6. Trigger a hardware register read from the powered-off device, producing a synchronous external abort.
7. Crash the kernel, resulting in denial of service and system reboot or outage.

How to detect it

To determine whether this issue has already been triggered, review kernel logs and persistent system journals for crash signatures involving the Wave5 VPU driver. Useful sources include dmesg output, systemd-journald kernel entries, /var/log/kern.log, /var/log/messages, serial console logs, crash dump storage, kdump/vmcore records, embedded device watchdog reboot logs, and hypervisor or appliance event logs that capture kernel panic output. Look for panics that occurred during video encoding, media device cleanup, suspend/resume, autosuspend, runtime PM transitions, or driver removal. Key artifacts include call traces referencing wave5_vdi_read_register, wave5_vpu_irq_work_fn, vpu_irq_thread, kthread_worker_fn, synchronous external abort, and kernel panic messages. Because this vulnerability is a local availability issue, logs usually will not show remote network indicators; correlation should focus on local user activity, container workloads, or media-processing jobs that accessed /dev/video* shortly before the crash.

• wave5_vdi_read_register
• wave5_vpu_irq_work_fn
• vpu_irq_thread
• Modules linked in: wave5
• Internal error: synchronous external abort
• Kernel panic - not syncing: synchronous external abort
• Fatal exception
• kthread_worker_fn
• wave5
• /dev/video

What your security team should do

• Inventory Linux systems, embedded devices, appliances, and media-processing nodes that use the Chips&Media Wave5 VPU driver or expose Wave5-backed /dev/video devices.
• Prioritize patching availability-critical systems that perform hardware-accelerated encoding or run untrusted local workloads with access to video devices.
• Obtain fixed kernel packages or BSP updates from the relevant Linux distribution, hardware vendor, or appliance vendor, and schedule deployment through normal kernel update procedures.
• Until patched, restrict permissions on affected video device nodes and prevent untrusted users or containers from accessing hardware media acceleration.
• Disable or blacklist the Wave5 driver on systems where the hardware encoder is not required.
• Monitor kernel logs for Wave5-related synchronous external aborts, VPU IRQ worker crashes, and kernel panics during video encoding or power-management transitions.
• For embedded or fleet-managed devices, include stress testing of video encode start/stop and suspend/resume behavior before broad rollout of fixed firmware or kernels.