CVE-2026-43310

What it actually does

This is a local denial-of-service flaw in the Linux kernel media subsystem affecting the VeriSilicon/Hantro VPU driver on platforms such as i.MX8MQ. The issue occurs because the G1 and G2 video processing units can be scheduled to decode H.264 and HEVC workloads simultaneously even though the hardware cannot safely do so. Concurrent decoding can trigger VPU bus errors, corrupted decoded frames, decode timeouts, and potentially a system hang. The impact is availability-only: there is no indication of confidentiality or integrity compromise beyond corrupted media output.

Why it matters to the business

Systems that rely on affected Linux kernels for hardware-accelerated video decoding may experience service disruption, device freezes, degraded media processing, or unexpected reboots/hangs if local users or workloads trigger simultaneous VPU activity. This is most relevant to embedded Linux, edge devices, appliances, kiosks, cameras, media gateways, and industrial systems using i.MX8MQ-class hardware. The vulnerability is not known to be exploited in the wild, is not in CISA KEV, has very low EPSS, and requires local access, so urgency is generally moderate unless affected devices provide untrusted users, containers, applications, or media-processing jobs access to V4L2/video decode devices.

How an attack unfolds

An attacker first needs local execution capability on an affected Linux system and access to the video decode device interface, typically through V4L2 media nodes exposed as /dev/video* or related device files. The attacker then starts concurrent decode workloads that exercise both H.264 and HEVC paths, causing the G1 and G2 VPUs to operate at the same time. Because the vulnerable driver scheduling does not serialize those hardware engines correctly, the platform can encounter a VPU bus error. Depending on timing and workload, the result may be corrupted decoded output, kernel log errors, decode timeouts, stalled media services, or a full system hang requiring service restart or device reboot.

How to fix it

Upgrade to a Linux kernel version or vendor BSP release that includes the VeriSilicon/Hantro VPU scheduling fix for this issue. The fix ensures G1 and G2 share the same v4l2_m2m_dev scheduling path so they operate alternately rather than simultaneously. Because no specific fixed version was provided, obtain patched kernels from the device vendor, Linux distribution, SoC vendor, or long-term-support kernel branch used by the product. If immediate patching is not possible, restrict access to video decode device nodes to trusted users and services only, remove unnecessary group permissions, avoid exposing V4L2 decode devices into containers or sandboxes, disable hardware-accelerated decode where operationally acceptable, and monitor for VPU bus errors or decode timeouts.

How to confirm the fix worked

Confirm the running kernel or vendor BSP contains the upstream fix for the media/verisilicon Hantro VPU scheduling change. Validate that local permissions on /dev/video*, /dev/media*, and related V4L2 device nodes are limited to trusted principals. On affected hardware, run controlled regression testing with simultaneous H.264 and HEVC hardware decode workloads and verify that decoding is serialized successfully, no VPU bus errors occur, no frame decode timeouts are logged, and the system remains responsive. Review kernel logs after testing using dmesg or journalctl -k for hantro-vpu, bus error, and frame decode timeout messages.

Typical attack path

1. Obtain local code execution or shell access on an affected Linux-based device.
2. Confirm access to hardware video decode interfaces such as V4L2 /dev/video* nodes.
3. Launch or script multiple hardware-accelerated H.264 and HEVC decoding sessions concurrently.
4. Force the G1 and G2 VPUs to decode simultaneously on hardware that requires them to operate alternately.
5. Trigger VPU decode timeout and bus error conditions.
6. Cause media-processing failure, corrupted output, service unavailability, or system hang.

How to detect it

To determine whether this was already triggered, review kernel logs, system journals, crash logs, watchdog reset records, and media service logs for Hantro/VeriSilicon VPU failures occurring during concurrent H.264 or HEVC decoding. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, persistent pstore/ramoops logs, systemd-coredump metadata, container runtime logs for workloads granted video device access, and application logs from media transcoders or players. Look for sequences where multiple decode sessions are started shortly before messages such as frame decode timed out or bus error detected from hantro-vpu. Correlate these events with local user sessions, container launches, ffmpeg/gstreamer workloads, or application jobs accessing /dev/video* or /dev/media*. Because this is a local availability issue, indicators are primarily kernel and device-driver artifacts rather than network IOCs.

• hantro-vpu 38310000.video-codec: frame decode timed out.
• hantro-vpu 38310000.video-codec: bus error detected.
• frame decode timed out
• bus error detected
• hantro-vpu
• 38310000.video-codec
• /dev/video
• /dev/media
• v4l2_m2m_dev
• H.264
• HEVC

What your security team should do

• Inventory Linux-based devices and products using i.MX8MQ or VeriSilicon/Hantro VPU hardware acceleration.
• Prioritize patching for embedded, edge, appliance, kiosk, camera, or media-processing systems where untrusted users, applications, or containers can access video decode devices.
• Update to a kernel, BSP, or distribution package that includes the Hantro VPU G1/G2 scheduling fix.
• Restrict permissions on V4L2 and media device nodes so only trusted services can access hardware decode interfaces.
• Avoid passing /dev/video*, /dev/media*, or GPU/VPU device nodes into untrusted containers until patched.
• Temporarily disable hardware-accelerated H.264/HEVC decode if service availability is more important than decode performance.
• Add monitoring for kernel log messages indicating hantro-vpu decode timeouts, bus errors, and repeated media driver failures.
• If bus errors or hangs are observed, preserve kernel logs and workload context, then reboot or restart affected media services as needed while applying the permanent kernel fix.