CVE-2024-27079

What it actually does

NULL pointer dereference in intel_iommu_release_device when info->domain is unassigned under deferred_attach mode during device release in the kdump kernel, leading to spinlock on a NULL address.

Why it matters to the business

Crash dumps may fail to be collected after a primary kernel panic, impairing forensic analysis and recovery workflows on affected Linux systems.

How an attack unfolds

No active attacker exploitation is required; the flaw manifests automatically when the kdump kernel attempts to remove PCI devices that were never fully attached due to deferred_attach mode.

How to fix it

Apply a kernel update containing the fix that uses the release_domain mechanism and clears scalable-mode context entries in release_device; rebuild and deploy initramfs as needed.

How to confirm the fix worked

Confirm the patch is present by inspecting intel_iommu.c for the release_domain handling logic and test kdump device removal paths on hardware with VT-d enabled.

Typical attack path

1. Trigger a primary kernel panic on a system using Intel VT-d IOMMU
2. Boot into the kdump capture kernel configured with deferred_attach
3. PCI device removal during i801 or similar driver probe invokes release_device with NULL domain
4. Kernel dereferences NULL in do_raw_spin_lock

How to detect it

Inspect kernel logs and crash reports for NULL pointer dereference at do_raw_spin_lock or intel_iommu_release_device called from iommu_deinit_device during PCI device removal in a kdump context.

What your security team should do

• Prioritize kernel updates on systems that rely on kdump for crash analysis
• Validate kdump functionality after patching
• Monitor upstream stable kernel releases for backports