CVE-2026-43301

What it actually does

This is a local Linux kernel denial-of-service flaw in the Chips&Media Wave5 media driver runtime power-management cleanup path. During device or module removal, the driver can decrement the runtime PM usage counter when it is already zero, causing a usage-count underflow. The observed failure mode is a kernel warning during module unload involving runtime PM and worker-thread cleanup. Because exploitation requires local privileges and interaction with the affected driver path, the primary impact is local system instability or denial of service rather than confidentiality or integrity compromise.

Why it matters to the business

Systems using Linux kernels with the affected Chips&Media Wave5 video codec driver may experience kernel warnings, device-driver instability, failed module unloads, or service disruption when the affected media device is removed or the driver is unloaded. The risk is most relevant to embedded Linux, appliances, media-processing systems, and devices using affected video codec hardware. This issue is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, organizations operating affected hardware should still remediate through normal kernel maintenance because local crashes or device instability can affect availability.

How an attack unfolds

An attacker first needs local access with sufficient privileges to interact with the affected kernel driver lifecycle, such as loading, unloading, or otherwise triggering removal of the Wave5 media driver/device. The system must include the affected Chips&Media Wave5 driver and be in a state where runtime autosuspend has already reduced the PM usage count to zero. The attacker then triggers the remove path, for example through module unload or device unbind/removal. The vulnerable code calls the wrong runtime PM decrement function unconditionally, pushing the usage counter below zero. This can produce kernel warnings and driver cleanup failures and may lead to local denial of service or operational instability on affected systems.

How to fix it

Update to a Linux kernel build that includes the upstream fix for the Chips&Media Wave5 runtime PM remove-path bug. Because no specific packaged fixed versions were provided, use the latest stable kernel or vendor-supported kernel release that backports the fix replacing the incorrect remove-path pm_runtime_put_sync() behavior with the corrected runtime PM autosuspend cleanup logic. For systems that cannot be updated immediately, reduce exposure by preventing untrusted users from loading, unloading, or unbinding kernel modules/devices; restrict access to media/video device nodes; disable or blacklist the affected Wave5 driver if the hardware functionality is not required; and avoid runtime driver removal on production systems until patched.

How to confirm the fix worked

Confirm the running kernel package or source tree includes the fix for the Chips&Media Wave5 driver runtime PM cleanup path. On source-based systems, verify the affected driver no longer unconditionally calls pm_runtime_put_sync() in the remove path and instead correctly pairs autosuspend setup and teardown. On packaged systems, validate against the distribution or hardware vendor advisory/changelog. After updating, reboot into the fixed kernel and test driver unload, device unbind, or controlled removal while monitoring dmesg or the system journal for absence of runtime PM usage-count underflow warnings. Also verify that the Wave5 video codec device continues to initialize and operate normally after the update.

Typical attack path

1. Gain local access to a Linux system that includes the affected Chips&Media Wave5 media driver.
2. Confirm the affected video codec device or driver is present and active.
3. Allow or force the device into an autosuspended runtime PM state where the usage count is already zero.
4. Trigger the driver remove path, such as by unloading the module, unbinding the device, or removing the device.
5. Cause the runtime PM usage count underflow, producing kernel warnings and potential driver or system instability.

How to detect it

To determine whether this condition has already been triggered, review kernel logs and system journals for runtime PM underflow warnings associated with the Chips&Media Wave5 driver or video codec device. Relevant sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, audit logs for module management, and any EDR telemetry covering privileged commands. Look for warnings around module unload, device unbind, runtime suspend/resume, or video-codec device removal. Also review command history and audit events for modprobe, rmmod, insmod, modprobe -r, writes to /sys/bus/*/drivers/*/unbind, and unexpected access to media/video device nodes. Because this vulnerability primarily causes local kernel instability rather than a persistent compromise artifact, detection should focus on crash/warning evidence and suspicious local attempts to manipulate kernel driver state.

• Runtime PM usage count underflow
• vdec 30210000.video-codec: Runtime PM usage count underflow!
• WARNING: CPU:
• kthread_destroy_worker
• media: chips-media: wave5
• chips-media
• wave5
• video-codec
• pm_runtime_put_sync
• pm_runtime_use_autosuspend
• pm_runtime_disable
• /sys/bus/platform/drivers
• /unbind
• rmmod
• modprobe -r
• insmod
• modprobe
• /dev/video
• /dev/media

What your security team should do

• Prioritize remediation on embedded, appliance, media-processing, or edge systems that use Chips&Media Wave5 video codec hardware.
• Upgrade affected systems to a vendor-supported kernel containing the upstream fix; reboot into the updated kernel and confirm the running kernel version changed.
• If immediate patching is not possible, restrict local administrative access, kernel module management, device unbind operations, and access to relevant media device nodes.
• Blacklist or disable the affected Wave5 driver where the video codec hardware is not operationally required.
• Monitor kernel logs for runtime PM usage-count underflow warnings and repeated driver unload, bind, unbind, or module-management activity.
• Treat exploitation risk as lower priority than remotely exploitable kernel issues because this requires local access and is not currently KEV-listed, but still address it in normal availability-focused patch cycles.