CVE-2024-26786

What it actually does

Logic error in iommufd allows iopt_access_list_id to be overwritten when xa_alloc succeeds but iopt_calculate_iova_alignment fails, producing a pointer mismatch in the access list and triggering a kernel WARN_ON during access destroy.

Why it matters to the business

Linux systems using IOMMU device passthrough or virtualization may experience kernel warnings, unexpected process termination, or reduced stability when IOMMU access objects are created and destroyed under load.

How an attack unfolds

An attacker with local access crafts a sequence of iommufd access change and destroy operations that hit the narrow window where the list ID is overwritten; this mismatch is detected on object removal and may be leveraged for further memory corruption if additional flaws exist.

How to fix it

Upgrade the Linux kernel to a version containing commit f1fb745ee0a6fe43f1d84ec369c7e6af2310fda9 or later; rebuild and reboot with the patched kernel; verify the commit is present via git log or kernel version string.

How to confirm the fix worked

Confirm the patched commit appears in the running kernel source; attempt to reproduce the original syzkaller reproducer and verify the WARN_ON no longer occurs; monitor kernel logs for absence of the iommufd access list ID mismatch warning.

Typical attack path

1. Obtain local unprivileged access on a Linux system with IOMMU support
2. Open and configure an iommufd context
3. Call iommufd_access_change_ioas while forcing iopt_calculate_iova_alignment to fail after xa_alloc succeeds
4. Trigger iommufd_access_destroy_object to hit the mismatched list entry and WARN
5. Repeat or combine with other primitives to attempt escalation

How to detect it

Review kernel logs for the exact WARN_ON string referencing drivers/iommu/iommufd/io_pagetable.c:1360 and iopt_access_list_id; inspect ftrace or audit logs around iommufd_access_change_ioas and close syscalls for anomalous IOMMU object lifetimes.

What your security team should do

• Prioritize kernel updates on systems that expose iommufd or use IOMMU passthrough
• Apply the fix within normal patch cycles unless the host performs heavy device assignment workloads
• Add kernel warning monitoring for iommufd access list messages to detect similar issues early