CVE-2026-43263

What it actually does

This is a race condition in the Linux kernel Chips&Media Wave5 media decoder driver. When multiple decoder instances are created and destroyed while interrupts are being handled, shared decoder state, including struct vpu_instance, can be accessed after it has been removed or before it is safely synchronized. The result is a NULL pointer dereference or other unsafe kernel-state access in interrupt-handling flow. Because the flaw occurs in kernel space, successful triggering can crash the system and, depending on surrounding memory/control-flow conditions and kernel hardening, may create broader local compromise risk. Exploitation requires local access and low privileges; it is not a remote network vulnerability by itself.

Why it matters to the business

Affected Linux systems that expose or use the Wave5 media decoder driver may be vulnerable to local disruption or compromise. A local user, compromised application, container workload with access to the relevant media device, or malicious media-processing workflow could potentially crash the host or interfere with workloads that depend on video decoding. The issue is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity reported, so broad opportunistic exploitation is less likely; however, kernel vulnerabilities should still be treated seriously because they can affect system stability and isolation boundaries.

How an attack unfolds

An attacker first needs local execution on a system with the affected Linux kernel and the Chips&Media Wave5 media decoder driver available. The attacker then interacts with the media decoder interface, repeatedly creating and destroying decoder instances while causing the device to generate interrupts. By racing teardown of decoder structures against interrupt handling, the attacker attempts to make kernel interrupt code reference shared decoder state after it has become NULL or invalid. A successful trigger can produce a kernel oops, panic, or potentially unsafe kernel behavior. In the most likely outcome this is a local denial-of-service condition; on systems with weaker hardening or additional driver-specific primitives, security teams should also consider the possibility of local privilege-impacting exploitation even though no public exploit is currently known.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the upstream fix for the Chips&Media Wave5 driver race condition. The fix changes interrupt handling into safer phases and adds locking around shared decoder state. No exact fixed version was provided in the input, so use your Linux distribution, appliance vendor, or board-support-package advisory to identify the first patched kernel for your platform. If immediate patching is not possible, reduce exposure by disabling or unloading the affected Wave5 media driver where it is not required, restricting access to video/media device nodes to trusted users and services only, and avoiding untrusted workloads that can access hardware media decoder interfaces. Kernel lockdown, device cgroup restrictions, container device isolation, and least-privilege access to /dev/video* devices can reduce practical exploitability but should not be treated as a complete fix.

How to confirm the fix worked

Confirm the running kernel package includes the vendor fix for the Wave5 driver race condition, not only that source packages have been updated. Validate with uname -r, package-manager metadata, vendor advisories, and changelogs referencing the Chips&Media Wave5 NULL reference/race-condition fix. Check whether the affected driver is present or loaded using module listings and kernel configuration review. If the driver is not present, not built, or not accessible to untrusted users, practical exposure is reduced. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is not still active. Where feasible, run controlled regression or media-decoder stress tests that create and destroy multiple decoder instances while monitoring dmesg/journal logs for kernel oops, NULL pointer dereference, IRQ-handler crashes, or wave5-related faults.

Typical attack path

1. Obtain local code execution on a Linux system with the affected Wave5 media decoder driver present and accessible.
2. Confirm access to the relevant media/video device interface used by the Wave5 decoder.
3. Run a workload that rapidly creates and destroys multiple decoder instances.
4. Simultaneously generate decoder activity that causes frequent interrupts.
5. Win the race between decoder instance teardown and interrupt-handler access to shared struct vpu_instance state.
6. Trigger a NULL pointer dereference or unsafe kernel access, causing kernel oops, panic, service disruption, or possible further local compromise depending on platform conditions.

How to detect it

To determine whether this was already exploited or accidentally triggered, review kernel logs rather than application logs. Relevant sources include dmesg output, systemd journal kernel entries, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, pstore/ramoops records on embedded systems, and endpoint telemetry that captures kernel panics or abnormal reboots. Look for crashes involving the Wave5 driver, Chips&Media media decoder, VPU decoder paths, IRQ handlers, NULL pointer dereferences, kernel oops reports, use-after-teardown-like symptoms during video decoding, and repeated system resets while media decoder workloads are active. Correlate events with local users, containers, jobs, or services that accessed video/media device nodes shortly before the crash. There are no public exploit-specific network indicators for this vulnerability because exploitation is local and device-driver focused. Treat repeated wave5-related kernel faults after media device access as suspicious, especially if caused by an untrusted user or workload.

• wave5
• chips-media
• chips_media
• vpu_instance
• NULL pointer dereference
• kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic
• irq handler
• IRQ handler
• /dev/video
• /dev/media
• /var/log/kern.log
• /var/log/messages
• pstore
• ramoops
• vmcore

What your security team should do

• Identify Linux systems that include or load the Chips&Media Wave5 media decoder driver, especially embedded, media-processing, ARM/SoC, appliance, and edge systems.
• Prioritize patching systems where untrusted users, containers, sandboxed applications, or media-processing services can access video/media device nodes.
• Upgrade to the vendor kernel containing the Wave5 locking and interrupt-handler fix, then reboot to ensure the patched kernel is running.
• If patching is delayed, disable the affected driver or remove access to the relevant /dev/video* and media device nodes for nonessential users and workloads.
• Review device passthrough and container runtime policies to ensure untrusted containers are not granted unnecessary access to host media decoder devices.
• Monitor kernel logs for wave5, vpu, IRQ-handler, NULL pointer dereference, kernel oops, and panic messages that could indicate attempted triggering.
• Because this is not KEV-listed, has very low EPSS, and has no known public exploit, handle as a normal kernel patching priority unless the affected hardware is exposed to untrusted local workloads or forms part of critical media-processing infrastructure.