CVE-2026-46210

What it actually does

This is a Linux kernel use-after-free in the media iris driver. During concurrent media/video instance handling, one thread can free per-instance format structures such as fmt_src and fmt_dst while another thread walks the global list of active instances for Macro Blocks Per Frame checks and dereferences those freed pointers. A local attacker with access to the affected media device interface could potentially trigger kernel memory corruption, causing a denial of service through a kernel crash and, depending on exploitability on a given build and hardening configuration, potentially escalating privileges or executing code in kernel context.

Why it matters to the business

Systems running affected Linux kernels with the vulnerable iris media driver exposed to local users, containers, applications, or multimedia workloads could be destabilized or potentially compromised by a low-privileged local attacker. The vulnerability is not listed in CISA KEV, has no known mature public exploitation in the supplied data, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, because successful exploitation can affect kernel integrity and availability, organizations should prioritize patching shared Linux hosts, developer workstations, mobile/edge devices, and systems where untrusted users or workloads can access video/media device nodes.

How an attack unfolds

An attacker first needs local execution capability on a system running an affected Linux kernel and access to the relevant media/video device interface. The attacker then creates concurrent operations against the iris media driver, such as opening media instances, configuring formats, triggering MBPF-related checks, and closing instances in carefully timed parallel threads. The race condition allows one path to free fmt_src or fmt_dst while the instance remains visible in the core list. A second path then walks that list and dereferences the stale pointer. In a simple exploitation scenario this causes a kernel oops, panic, or device instability. In a more advanced scenario, the attacker attempts to groom kernel memory so the freed object is replaced with attacker-influenced data, potentially converting the stale dereference into privilege escalation or kernel code execution.

How to fix it

Update affected Linux kernels to a version that includes the upstream fix for the iris driver teardown ordering issue. Because no exact fixed package versions were provided, use the fixed kernel versions from the relevant Linux distribution, device vendor, or kernel maintenance branch once published. The corrective change should ensure fmt_src and fmt_dst are not freed until after the instance has been removed from the core list and teardown protected by the core lock has completed. Where immediate patching is not possible, reduce exposure by restricting access to affected media/video device nodes, disabling or unloading the iris driver if it is not required, limiting untrusted local shell/container access, and applying kernel hardening features such as KASLR, SMEP/SMAP where available, and mandatory access controls for device access.

How to confirm the fix worked

Confirm the running kernel package or build includes the vendor fix for this issue. Validate by checking the distribution security advisory, kernel changelog, or source tree for the iris driver fix that defers freeing fmt_src and fmt_dst until after removal from the core active-instance list. On hosts where the driver is not required, confirm it is not loaded. On hosts where it is required, confirm access to relevant /dev/video* or media device nodes is restricted to trusted users and services. After patching, run representative media workloads and monitor kernel logs for new iris, V4L2, KASAN, use-after-free, general protection fault, or kernel oops messages.

Typical attack path

1. Gain low-privileged local code execution on a system running an affected Linux kernel.
2. Confirm access to the affected media/video device interface, such as a V4L2 video device backed by the iris driver.
3. Run a multithreaded workload that repeatedly opens, configures, and closes media instances while triggering MBPF checks.
4. Win the race where iris_close() frees fmt_src or fmt_dst before the instance is removed from the core active-instance list.
5. Cause the MBPF checker to dereference the freed fmt_src pointer while iterating the core list.
6. Achieve a kernel crash/denial of service, or attempt memory grooming to turn the use-after-free into privilege escalation.

How to detect it

Review kernel logs and crash telemetry for evidence of media iris driver instability or memory-safety faults. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps, kdump/vmcore analysis, audit logs for access to media device nodes, and endpoint telemetry showing processes repeatedly opening /dev/video* or /dev/media* devices. Look for KASAN reports, kernel oopses, panics, general protection faults, or call traces referencing iris driver functions, MBPF checks, fmt_src, fmt_dst, V4L2, or media device teardown. Because exploitation requires local interaction and may look like a crash rather than a network event, correlate kernel faults with local user sessions, container workloads, unusual multimedia test binaries, fuzzers, or processes performing high-frequency open/close/ioctl activity against video devices. No named threat actors, ransomware use, or confirmed exploitation were provided in the input, so detections should focus on host-level crash artifacts and suspicious local device access rather than external network indicators.

• BUG: KASAN: use-after-free
• use-after-free
• iris_close
• fmt_src
• fmt_dst
• MBPF
• media: iris
• iris
• v4l2
• /dev/video
• /dev/media
• general protection fault
• kernel BUG
• kernel panic
• Oops:
• Call Trace:

What your security team should do

• Inventory Linux systems using kernels that include the iris media driver, especially endpoints, embedded devices, mobile/edge systems, and hosts with video/media hardware exposed.
• Prioritize patching systems where untrusted users, build jobs, containers, desktop applications, or multimedia workloads can access local media device nodes.
• Apply the vendor-provided fixed kernel package when available; if building custom kernels, backport the upstream iris teardown-ordering fix.
• Restrict permissions on /dev/video*, /dev/media*, and related device nodes to trusted users and services only.
• Disable or unload the iris media driver on systems that do not require it.
• Monitor kernel logs for use-after-free, KASAN, oops, panic, or iris/V4L2 crash indicators, especially after suspicious local user activity.
• Treat unexpected kernel crashes on affected systems as potentially security-relevant until logs and device-access activity are reviewed.