Recently, a bug affecting the Linux kernel’s IOMMU (Input/Output Memory Management Unit) code was disclosed and patched under CVE-2024-27079. This critical issue, specifically found in the Intel VT-d driver, could lead to a kernel crash in certain situations – most notably when running crash kernels (kdump). In this article, we’ll break down what went wrong, how attackers might exploit this bug, and how the vulnerability was fixed.

What is CVE-2024-27079?

CVE-2024-27079 describes a bug in the Linux kernel’s Intel VT-d IOMMU driver. When the kernel is running in “crash kernel” mode (kdump), it uses “deferred_attach” mode for IOMMU. In this mode, the info->domain pointer can still be unset when the kernel tries to release a device. The missing check before dereferencing this pointer can lead to a kernel panic due to a NULL pointer dereference.

Affected Component:
- File: drivers/iommu/intel/iommu.c

Technical Details

When a device is removed or released, the kernel’s IOMMU code needs to perform cleanup. In “deferred_attach” mode, the domain attached to the device (info->domain) might not be set. However, the driver did not check if this pointer was NULL before using it, resulting in a crash like the following:

BUG: kernel NULL pointer dereference, address: 000000000000003c
...
RIP: 001:do_raw_spin_lock+xa/xa
...
intel_iommu_release_device+x96/x170
iommu_deinit_device+x39/xf
__iommu_group_remove_device+xa/xd
...

Vulnerable Code Example (before patch)

// File: drivers/iommu/intel/iommu.c

static void intel_iommu_release_device(struct device *dev)
{
    struct device_domain_info *info = dev->archdata.iommu;
    // ... missing NULL check for info->domain ...
    spin_lock_irqsave(&info->domain->lock, flags);
    // ... rest of cleanup ...
}

If info->domain is NULL, as can happen in deferred_attach mode, accessing info->domain->lock crashes the kernel.

Exploitation Scenario

While this bug does not allow arbitrary code execution, it enables a local attacker (or an attacker with access to kernel module loading/unloading or device hot-plug operations) to crash the kernel deliberately, resulting in a Denial of Service (DoS).

Minimal Exploit Trigger in Pseudo-Code

// Assuming attacker can trigger hot-removal of device in kdump kernel
remove_pci_device(device);  // triggers device_del() and eventually release_device()

Result: System falls over, kdump cannot finish collecting crash data.

The Fix

The proper solution is to check whether info->domain is NULL before trying to use it. Additionally, cleanup for scalable mode’s context entry is now done unconditionally in release_device(), and the main release is protected using the release_domain mechanism.

Patch Example

 static void intel_iommu_release_device(struct device *dev)
 {
     struct device_domain_info *info = dev->archdata.iommu;
-    spin_lock_irqsave(&info->domain->lock, flags);
-    // cleanup
+    if (info->domain) {
+        spin_lock_irqsave(&info->domain->lock, flags);
+        // cleanup
+        spin_unlock_irqrestore(&info->domain->lock, flags);
+    }
+    // Always clear scalable mode context entry, even if domain is NULL
     // ... rest of cleanup ...
 }

Official References

- Upstream kernel fix commit
- CVE entry on Mitre
- LKML discussion

How to Stay Safe

- Update your Kernel: If you’re running vulnerable versions, apply the latest security updates from your distribution.

Check Your IOMMU Use: If you use kdump and VT-d, make sure you're running a patched kernel.

- Restrict local access: Don’t allow untrusted users to hot-plug or remove devices on production servers.

Conclusion

CVE-2024-27079 offers a prime example of how missing a simple NULL check can have disastrous consequences in kernel code. While not allowing privilege escalation directly, it can still be used for DoS attacks in special kernel configurations. Patch early—kernel bugs wait for no one!

If you found this helpful, share or discuss with your Linux admin friends! For deeper technical breakdowns, stay tuned to the Linux Kernel Mailing List or your distro’s security team.

Timeline

Published on: 05/01/2024 13:15:51 UTC
Last modified on: 03/05/2025 15:11:27 UTC