CVE-2026-43222

What it actually does

This is a local Linux kernel buffer overflow in the Verisilicon media AV1 decoder path. The driver allocates an undersized tile-info buffer and then writes AV1 tile metadata entries containing row, column, start position, and end position fields beyond the allocated memory. Because the write occurs in kernel context, a local user who can reach the affected media device interface may be able to corrupt kernel memory, causing a denial of service or, depending on heap layout and exploitability, escalating privileges or disclosing/modifying sensitive kernel data.

Why it matters to the business

Systems that expose the affected Linux media decoder to local users, containers, kiosk sessions, browsers, or media-processing workloads could be crashed or potentially taken over from a low-privileged account. The EPSS score is currently very low, there is no known public exploit maturity, and it is not listed in CISA KEV, but kernel memory-corruption flaws with local privilege-escalation potential should still be prioritized on shared Linux hosts, appliances, edge devices, and systems that process untrusted video content.

How an attack unfolds

An attacker first needs local code execution or access to an application path that can submit AV1 content to the affected Verisilicon hardware decoder, commonly through a V4L2 media device exposed as a video device node. The attacker provides a crafted AV1 stream with tile layout values that cause the driver to populate more tile-info data than the incorrectly sized buffer can hold. When the kernel driver processes the stream, it writes tile metadata past the end of the allocation. In the simplest case this triggers a kernel oops, panic, or media subsystem crash. With reliable heap shaping, an attacker may attempt to overwrite adjacent kernel objects to gain elevated privileges or tamper with kernel memory. Exploitation is constrained to systems with the affected driver and AV1 decode path enabled and reachable by the attacker.

How to fix it

Upgrade to a Linux kernel build from the operating system or device vendor that includes the upstream fix for the Verisilicon AV1 tile-info buffer allocation issue. No exact fixed package versions were provided in the input, so remediation should be verified through vendor advisories, kernel changelogs, or source/package metadata for the patch titled "media: verisilicon: AV1: Fix tile info buffer size." If immediate patching is not possible, reduce exposure by disabling or blacklisting the affected Verisilicon/Hantro media driver where it is not required, disabling AV1 hardware decoding, restricting access to /dev/video* and related media device nodes to trusted users only, and avoiding pass-through of media devices into containers or sandboxed workloads that process untrusted files.

How to confirm the fix worked

Confirm the running kernel is a vendor-supported build that includes the Verisilicon AV1 buffer-size fix, not just that the package is installed. Validate with a combination of kernel package changelogs, vendor security advisory status, source patch review, and the running kernel version from uname. On source-based or custom kernels, verify that the AV1 tile-info allocation uses the correct size of AV1_MAX_TILES multiplied by the full tile-info entry size. Also confirm whether the affected driver is built or loaded, whether Verisilicon/Hantro media devices are present, and whether untrusted users or containers can access /dev/video* or media controller devices. After remediation, ensure no recurring kernel oops, KASAN, slab out-of-bounds, or media decoder crashes appear during AV1 decoding tests.

Typical attack path

1. Gain local, low-privileged execution on a Linux system or access to a service/container that can use the affected media decoder.
2. Confirm that Verisilicon/Hantro media decoding is present and that a V4L2 media device such as /dev/video* is accessible.
3. Submit a crafted AV1 bitstream with tile metadata designed to exceed the undersized tile-info allocation.
4. Trigger the AV1 decode path in the kernel media driver.
5. Cause an out-of-bounds kernel memory write, resulting in a crash or attempted kernel memory corruption.
6. If exploit development is successful, leverage corrupted kernel state to escalate privileges or bypass isolation.

How to detect it

There are no public exploitation indicators specific to this vulnerability, so detection should focus on signs of attempted kernel memory corruption through the media decoding path. Review kernel logs from dmesg, journalctl, syslog, crash dumps, and centralized EDR telemetry for kernel oops, panics, KASAN reports, slab out-of-bounds messages, general protection faults, or BUG/WARN traces involving Verisilicon, Hantro, V4L2, AV1, or drivers/media/platform/verisilicon. Investigate unexpected access to /dev/video*, /dev/media*, or V4L2 decoder devices by low-privileged users, containers, browsers, media parsers, file-preview services, or untrusted workloads. On systems with auditd or eBPF telemetry, look for unusual open/ioctl activity against media device nodes followed by kernel faults. If crash dumps are available, inspect stack traces for AV1 decode functions in the Verisilicon/Hantro media driver and look for adjacent heap corruption around tile-info processing.

• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• slab-out-of-bounds
• kernel BUG
• general protection fault
• Oops:
• panic: Fatal exception
• drivers/media/platform/verisilicon
• verisilicon
• hantro
• AV1
• v4l2
• /dev/video
• /dev/media
• ioctl

What your security team should do

• Prioritize patching shared Linux systems, media-processing servers, edge devices, appliances, and systems where untrusted users or containers can access hardware video decoding.
• Inventory systems with Verisilicon/Hantro media drivers enabled and identify which expose /dev/video* or media controller devices to non-admin users.
• Apply vendor kernel updates that include the upstream fix; for custom kernels, backport the patch and rebuild.
• Temporarily restrict device-node permissions or remove media-device pass-through from containers until patching is complete.
• Disable or blacklist the affected media driver on systems that do not require Verisilicon AV1 hardware decoding.
• Monitor kernel logs for crashes or memory-corruption reports involving the media subsystem, Verisilicon, Hantro, V4L2, AV1 decoding, KASAN, or slab out-of-bounds errors.
• Because the issue is not currently in KEV and EPSS remains low, treat it as high priority where local multi-user access or untrusted media decoding exists, and normal-priority kernel hygiene elsewhere.