CVE-2026-64421

What it actually does

This vulnerability is a use-after-free in the Linux kernel NXP i.MX8 ISI media driver. During driver removal, the cleanup sequence frees media entity pad structures in the ISI crossbar cleanup routine before the V4L2/media framework has finished unregistering entities and removing media links that still reference those pads. If the vulnerable removal path is exercised, the kernel may dereference freed slab memory in functions such as __media_entity_remove_link(), resulting in a kernel warning, KASAN finding, crash, or potentially undefined kernel memory behavior. Based on the available description, exploitation appears to require local ability to unload, unbind, or otherwise remove the imx8_isi driver/device path, and there is no public evidence of weaponized exploitation.

Why it matters to the business

Systems using affected Linux kernels on NXP i.MX8 platforms with the imx8_isi media driver may experience instability or denial of service when the driver is removed or the device is unbound. The most likely operational impact is a kernel crash or service disruption on embedded, industrial, camera, or edge devices that rely on this media pipeline. The low EPSS score and absence from the CISA KEV catalog indicate no known broad exploitation at this time, but organizations running long-lived embedded Linux deployments should still prioritize kernel maintenance because kernel memory-safety flaws can have outsized reliability and security consequences.

How an attack unfolds

An attacker or local user with sufficient privileges to manipulate kernel modules or device binding targets a system running an affected Linux kernel with the NXP i.MX8 ISI driver present. They trigger the driver's remove path, for example by unloading the imx8_isi module or unbinding the associated platform device. The vulnerable remove function calls the crossbar cleanup first, which frees media entity pads. The subsequent V4L2 cleanup then attempts to unregister media entities and remove links that still reference the freed pads. This causes a use-after-free in the kernel media subsystem, commonly visible as a KASAN slab-use-after-free report or kernel oops. In practical terms, the most credible attacker outcome is local denial of service through kernel crash or instability; reliable privilege escalation is not established from the available information.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the imx8-isi cleanup ordering issue. The fix changes the remove sequence so mxc_isi_v4l2_cleanup() runs before mxc_isi_crossbar_cleanup(), ensuring media entities are unregistered before the pad structures are freed. If vendor fixed package versions are not yet available, obtain patched kernels from the Linux stable tree, the device vendor, board support package provider, or distribution maintainer once released. As interim mitigation, avoid unloading or rebinding the imx8_isi driver on affected production systems, restrict root and administrative access, disable unnecessary module loading/unloading workflows, and avoid exposing device-management interfaces that can trigger driver removal to untrusted users. If the driver is not needed, consider disabling it in the kernel configuration or preventing it from loading, after validating that camera/media functionality is not required.

How to confirm the fix worked

Confirm the running kernel includes the patch that reorders cleanup in the imx8_isi driver so V4L2 cleanup occurs before crossbar cleanup in mxc_isi_remove(). Validate through vendor advisory mapping, kernel changelog review, source inspection, or package metadata. On test systems only, reproduce the previous failure mode by loading and unloading or binding and unbinding the imx8_isi driver while monitoring dmesg; a fixed kernel should not produce KASAN slab-use-after-free reports in __media_entity_remove_link(), mxc_isi_crossbar_cleanup(), or mxc_isi_remove(). Confirm whether the module is present with lsmod, modinfo, kernel configuration, or /sys/module checks, and confirm whether the hardware/driver path is actually in use on deployed devices.

Typical attack path

1. Identify a Linux system running on NXP i.MX8 hardware or otherwise loading the imx8_isi media driver.
2. Obtain local privileges sufficient to remove a kernel module or unbind the affected platform device.
3. Trigger the driver removal path using module removal, device unbind, or a management workflow that unloads the media driver.
4. Cause mxc_isi_remove() to execute the vulnerable cleanup order.
5. Kernel media cleanup dereferences freed media entity pad memory during link removal.
6. System records a KASAN use-after-free, kernel oops, panic, or instability, potentially causing denial of service.

How to detect it

Look for evidence that the vulnerable driver removal path was exercised and caused kernel memory errors or crashes. Primary log sources are kernel logs, dmesg output, journald kernel facility logs, /var/log/kern.log, /var/log/messages, crash dumps, pstore/ramoops, kdump/vmcore data, and endpoint telemetry that records module unloads or sysfs device unbind events. Search for KASAN slab-use-after-free reports and stack traces referencing __media_entity_remove_link(), mxc_isi_remove(), mxc_isi_crossbar_cleanup(), mxc_isi_v4l2_cleanup(), v4l2_device_unregister_subdev(), or the imx8_isi module. Also correlate these events with administrative commands such as rmmod imx8_isi, modprobe -r imx8_isi, or writes to /sys/bus/platform/drivers/*/unbind. There are no known network indicators for this vulnerability, and absence of KASAN does not guarantee absence of exposure because many production kernels do not enable KASAN. For suspected exploitation, review privilege escalation attempts, recent root/admin sessions, device management automation, module unload audit events, and crash timing around media-device maintenance.

• BUG: KASAN: slab-use-after-free in __media_entity_remove_link
• slab-use-after-free in __media_entity_remove_link
• __media_entity_remove_link+
• __media_entity_remove_links+
• __media_device_unregister_entity+
• media_device_unregister_entity+
• v4l2_device_unregister_subdev+
• v4l2_async_unbind_subdev_one+
• v4l2_async_nf_unbind_all_subdevs+
• v4l2_async_nf_unregister+
• mxc_isi_remove+
• mxc_isi_crossbar_cleanup+
• mxc_isi_crossbar_init+
• mxc_isi_v4l2_cleanup
• [imx8_isi]
• rmmod imx8_isi
• modprobe -r imx8_isi
• /sys/bus/platform/drivers
• /unbind
• KASAN: slab-use-after-free
• kernel BUG
• kernel panic
• Oops:
• imx8_isi

What your security team should do

• Inventory Linux systems and embedded devices using NXP i.MX8 SoCs or the imx8_isi media driver.
• Prioritize patching systems where the imx8_isi driver is loaded and where local users, container workloads, automation, or management agents can trigger module unload or device unbind operations.
• Track kernel, distribution, and board-support-package advisories for the fixed build because no exact fixed package versions were provided in the input.
• Restrict module unload, module load, and sysfs device unbind capabilities to trusted administrators only.
• Monitor kernel logs for KASAN, oops, panic, or media subsystem traces referencing imx8_isi, mxc_isi_remove, or __media_entity_remove_link.
• For production embedded devices, avoid operational procedures that unload or rebind the ISI media driver until patched.
• If the ISI media driver is not required, disable or blacklist it after functional testing.
• Because this is not currently listed in KEV and has low EPSS, treat it as a targeted reliability and local kernel-hardening issue rather than an internet-scale emergency, unless the affected driver is broadly deployed in critical device fleets.