CVE-2026-45928

What it actually does

This is a local availability flaw in the Linux kernel Chips&Media Wave5 VPU media driver. In the encoder and decoder open paths, the driver allocates a VPU instance and then allocates codec-specific state. If the second allocation fails, the function returns an out-of-memory error without freeing the first allocation. Repeatedly triggering this failure path can leak kernel memory and may eventually degrade system performance or cause denial of service through memory exhaustion. The issue requires local access and the ability to interact with the affected media/VPU device; it does not provide confidentiality or integrity impact.

Why it matters to the business

Systems using Linux kernels with the affected Wave5 VPU driver may be vulnerable to local denial of service if an authenticated user, container workload with device access, or compromised local process can repeatedly exercise the vulnerable media device path. The most likely consequence is service instability, degraded performance, or a reboot caused by kernel memory pressure. Exploitation is not known to be active, the EPSS score is very low, and it is not in CISA KEV; however, systems that expose hardware video encode/decode devices to untrusted users or workloads should prioritize remediation because the impact is availability loss.

How an attack unfolds

An attacker first needs local execution on a system running an affected Linux kernel with the Chips&Media Wave5 VPU driver available. The attacker then identifies accessible media or video device nodes associated with the VPU driver and repeatedly attempts to open encoder or decoder contexts. To reach the vulnerable branch, the attacker attempts to create conditions where allocation of the codec_info structure fails after the VPU instance allocation has already succeeded, such as by inducing memory pressure while repeatedly exercising the device open path. Each failed allocation leaks the previously allocated instance object. Over many attempts, leaked kernel memory can accumulate, leading to increased memory pressure, degraded system responsiveness, failures in unrelated services, or system-level denial of service.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Chips&Media Wave5 VPU memory leak in wave5_vpu_open_enc() and wave5_vpu_open_dec(). No exact fixed package versions were provided in the input, so use the fixed kernel version supplied by the relevant Linux distribution, appliance vendor, or hardware platform maintainer. Where immediate patching is not possible, reduce exposure by disabling or unloading the Wave5 VPU driver if not required, removing access to associated /dev/video* or /dev/media* devices from untrusted users and containers, and avoiding device passthrough for workloads that do not need hardware video encode/decode. Apply normal kernel update procedures, including rebooting into the patched kernel where required.

How to confirm the fix worked

Confirm remediation by verifying the running kernel is the patched vendor build, not only that updated packages are installed. Check that the kernel source or vendor changelog includes the fix that frees the allocated VPU instance when codec_info allocation fails in the Wave5 encoder and decoder open paths. On systems where the hardware is present, verify whether the Wave5 module is loaded and whether media/video device nodes are exposed to untrusted users or containers. After patching or mitigation, confirm that the module is either updated, disabled, or access-controlled, and monitor kernel logs during functional media encode/decode tests for allocation failures, OOM events, or driver errors.

Typical attack path

1. Gain local code execution or access to a local account on a Linux system using the affected kernel driver.
2. Identify accessible media or video device nodes backed by the Chips&Media Wave5 VPU driver.
3. Repeatedly invoke encoder or decoder open operations against the affected device.
4. Create or wait for memory pressure so codec_info allocation fails after the VPU instance allocation succeeds.
5. Repeat the failure path to leak kernel memory.
6. Cause system instability, service failures, or denial of service as available kernel memory is exhausted.

How to detect it

To determine whether this may already have been exploited, review kernel logs, system journals, audit logs, and endpoint telemetry for repeated access to media or video devices followed by memory pressure, allocation failures, or OOM killer activity. Focus on systems with the Wave5 driver loaded or Chips&Media VPU hardware present. Useful log sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, auditd records for /dev/video* and /dev/media* access, container runtime logs showing device passthrough, and EDR process telemetry showing repeated open/ioctl activity against media devices. There is no unique remote network signature because exploitation is local. Suspicious patterns include a non-media workload repeatedly opening video/media device nodes, kernel allocation failure messages near Wave5 driver activity, rising unreclaimable kernel memory, and OOM events without a clear workload-driven cause.

• wave5
• wave5-vpu
• chips-media
• /lib/modules/*/kernel/drivers/media/platform/chips-media/wave5/
• /dev/video
• /dev/media
• allocation failure
• Out of memory: Killed process
• invoked oom-killer
• kzalloc
• codec_info
• wave5_vpu_open_enc
• wave5_vpu_open_dec

What your security team should do

• Inventory Linux systems using Chips&Media Wave5 VPU hardware or loading the Wave5 media driver.
• Prioritize patching systems where /dev/video* or /dev/media* devices are accessible to non-administrative users, containers, kiosks, shared compute environments, or untrusted workloads.
• Deploy the vendor-provided fixed kernel and reboot into it; verify the active kernel version after reboot.
• If patching is delayed, disable the Wave5 VPU driver or restrict device-node access using udev rules, cgroups, container runtime policy, or device passthrough controls.
• Monitor kernel logs and memory telemetry for repeated media-driver allocation failures, unexplained memory pressure, OOM killer activity, or local processes repeatedly opening media devices.
• Treat suspicious repeated access to VPU-backed media devices by untrusted users as potential denial-of-service activity, even though no public exploitation is currently reported.