CVE-2026-89452

What it actually does

The Qualcomm MSM IOMMU probe path inserts a devm-managed IOMMU object into the global qcom_iommu_devices list before completing sysfs setup and IOMMU-core registration. If iommu_device_sysfs_add() or iommu_device_register() fails, the function returns without reversing those steps. The driver core then frees the managed object, leaving a dangling list entry (and, on the register-failure path, a leftover sysfs device). Later walks of that list can dereference freed kernel memory—a use-after-free that can corrupt kernel structures and impact confidentiality, integrity, and availability.

Why it matters to the business

Linux systems using the Qualcomm MSM IOMMU driver (typical of Qualcomm SoC mobile, embedded, automotive, and IoT platforms) can suffer a local kernel compromise or crash if this probe-failure path is hit, with full loss of host confidentiality, integrity, and availability on a successful exploit (CVSS 8.4). The issue is not listed in CISA KEV, is not associated with ransomware, and has no public exploit thirty days after publication, so opportunistic mass exploitation is not indicated. Residual operational risk is highest where untrusted local code can run or where IOMMU devices can be rebound; unpatched kernels remain exposed until a patched kernel is deployed and booted.

How an attack unfolds

A local actor on a vulnerable Qualcomm MSM Linux system needs the MSM IOMMU driver to fail partway through probe—after the object is linked onto qcom_iommu_devices but after sysfs add or IOMMU-core registration has failed. Once the driver core releases the devm allocation, the list retains a dangling pointer. Any subsequent kernel path that walks qcom_iommu_devices can use the freed object, producing a use-after-free in kernel context that may be abused for memory corruption, privilege escalation, or a denial-of-service panic. Exploitation requires local presence and a rare probe-failure condition; there is no published exploit, named threat actor, or ransomware campaign tied to this defect.

How to fix it

Apply the upstream Linux kernel change that unwinds MSM IOMMU probe state in reverse setup order: on iommu_device_sysfs_add() or iommu_device_register() failure, unregister the sysfs device if it was added and remove the object from qcom_iommu_devices before returning. Deploy the vendor or distribution kernel that includes this fix and reboot onto that kernel. Exact fixed package versions were not supplied with this record—confirm the advisory for your distro, Android/OEM tree, or SoC vendor. Until a patched kernel is running, limit untrusted local code execution and restrict the ability to unbind, rebind, or otherwise retrigger IOMMU device probe. Network-only controls do not address this local kernel bug.

How to confirm the fix worked

Confirm the running kernel changelog or source contains the msm_iommu_probe unwind (removal from qcom_iommu_devices and sysfs teardown on registration failure). Match the installed kernel package to your distribution or OEM security advisory, then reboot and verify uname -r shows the patched build. On Qualcomm MSM platforms, review dmesg and the systemd journal around IOMMU probe for registration failures and for list-corruption or use-after-free oopses involving msm_iommu after boot or device rebind. Absence of the unwind in source or of a matching vendor advisory means the host is still exposed.

Typical attack path

1. Gain local execution on a Linux host that loads the Qualcomm MSM IOMMU driver
2. Cause msm_iommu_probe() to fail after the IOMMU object is added to qcom_iommu_devices but before successful sysfs and IOMMU-core registration
3. Allow the driver core to free the devm-managed object, leaving a dangling global list entry
4. Induce a kernel path that walks qcom_iommu_devices and dereferences the freed object
5. Abuse the resulting use-after-free for kernel memory corruption, privilege escalation, or a host crash

How to detect it

No in-the-wild exploitation, public exploit, or named actor is associated with this issue, so compromise is not expected to leave distinctive malware artifacts. Hunt historical kernel logs (dmesg, journald/kern.log, pstore/ ramoops, panic dumps, Android tombstones) on Qualcomm MSM systems for use-after-free, list corruption, or paging-request oopses whose call traces involve msm_iommu, qcom iommu registration, or walks of the IOMMU device list, especially around probe, sysfs add, or iommu_device_register failure. Correlate with local code execution, module load, or device unbind/bind around the same timestamp. A crash matching that pattern indicates the dangling-list condition was hit; it does not by itself prove intentional exploitation.

What your security team should do

• Inventory Linux hosts and images that include the Qualcomm MSM/QCOM IOMMU driver and treat them as in-scope until a patched kernel is confirmed running
• Prioritize kernel updates on multi-user, shared, or developer systems where local untrusted code can execute; reboot after patching
• Track distro, Android, and SoC-vendor advisories for this use-after-free until exact fixed versions are published for each tree you run
• Until patched, restrict local untrusted workloads and IOMMU device unbind/rebind capability; do not rely on network filtering as the primary control
• Hunt kernel logs for MSM IOMMU probe failures and list-corruption oopses, and re-evaluate if public exploit code or KEV listing appears