Linux Kernel CVE-2026-97513

Requires local access to the chips-media wave5 VPU M2M V4L2 device node (e.g., /dev/videoN, generally the 'video' group), a kernel built with the wave5 codec driver enabled, and the corresponding Chips&Media WAVE5 video-processing hardware present. The bug is a race: the attacker must close/release a codec instance while a codec interrupt is being serviced, so the IRQ thread acquires the spinlock between m2m_ctx release and the instance's removal from the active list. Limiting factors: local-only vector, driver present on only specific SoCs, and non-deterministic timing window make reliable triggering difficult; the observed outcome is a NULL-pointer dereference (crash), not confirmed code execution.

This is a CWE-416 use-after-free / NULL-pointer dereference race in the Linux kernel's chips-media wave5 VPU (video codec) driver, triggered when the IRQ thread grabs the instance spinlock in the narrow window between m2m_ctx release and wave5_release removing the stream instance from the active-instances list. The NVD CVSS of 7.8 (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) overstates real-world risk: the flaw is a teardown-vs-IRQ timing race, so AC:L is optimistic (winning the race is not deterministic → AC:H), and the demonstrated impact is a NULL-pointer dereference/oops, which is availability-dominant rather than the full C:H/I:H/A:H triad claimed. No EPSS score, no CISA KEV listing, and no public exploit are present in the data, so there is no signal of active or automatable exploitation. Net: a legitimate local DoS-class bug worth patching on affected systems, but not a broad emergency - it demands local access to the wave5 V4L2 device and precise timing, and the affected driver is deployed on only a small subset of hardware. Missing data to note: CWE is 'N/A' in the feed (should be CWE-416), and the vendor advisory provides only stable-tree commit hashes, not a narrative severity rating.

A local user with access to the wave5 V4L2 memory-to-memory video device (e.g., /dev/videoN, typically the video group) opens a decode/encode instance and then closes it while codec IRQ processing is still in flight. If the IRQ thread acquires the instance spinlock in the window after m2m_ctx is freed but before the instance is removed from the active list, it dereferences the freed/NULL m2m_ctx, causing a kernel oops and denial of service. No public exploit or POC is identified at time of analysis, and exploitation requires winning a race, so reliability is low.