CVE-2024-56624

What it actually does

Double release of fault object and IOMMU context after fput in iommufd_fault_alloc leads to refcount underflow, memory leak warnings, and imbalanced file reference counts.

Why it matters to the business

Kernel log spam, potential system instability during IOMMU fault handling, and resource leaks on affected Linux systems; low exploitation likelihood reduces immediate risk but still requires patching for stability.

How an attack unfolds

An attacker with local access triggers IOMMU fault allocation paths that exercise the faulty fput sequence, causing the kernel to decrement refcounts incorrectly and emit warnings; no remote or privilege-escalation path is known.

How to fix it

Upgrade to a kernel containing commit 2b3f30c8edbf9a122ce01f13f0f41fbca5f1d41d or later; apply vendor backports for stable trees; remove the duplicate release lines in iommufd_fault_alloc if building from source.

How to confirm the fix worked

Boot the patched kernel, exercise iommufd fault allocation and release paths under load, and confirm absence of refcount_warn_saturate and filp_flush warnings in dmesg.

Typical attack path

1. Obtain local access to a system running an affected kernel
2. Perform operations that allocate iommufd fault objects
3. Trigger close paths that invoke iommufd_fault_fops_release
4. Observe refcount warnings and potential memory accounting errors

How to detect it

Search kernel logs for refcount_warn_saturate, filp_flush, and __file_ref_put warnings mentioning iommufd; inspect processes closing files backed by iommufd_fops.

What your security team should do

• Prioritize kernel updates on systems using IOMMU and iommufd
• Monitor for refcount and file reference warnings in production logs
• Test IOMMU workloads after patching to verify stability