CVE-2024-56568

What it actually does

Race condition between arm_smmu_device_probe and client device probe allows null pointer dereference in arm_smmu_probe_device when of_dma_configure occurs after iommu_device_register but before driver_bound completes.

Why it matters to the business

Kernel crashes and denial of service on ARM Linux systems during device initialization, causing unplanned downtime and potential loss of service in embedded, server, and mobile deployments; low EPSS indicates limited in-the-wild exploitation but urgency rises on high-prevalence kernel branches.

How an attack unfolds

Attacker triggers concurrent really_probe calls for SMMU and a dependent client device; timing allows arm_smmu_get_by_fwnode to return null before klist_add_tail in driver_bound, resulting in dereference of smmu->streamid_mask inside arm_smmu_probe_device; similar kernel race patterns have been targeted by espionage and financially motivated actors in zero-day campaigns.

How to fix it

Apply the upstream fix at commit c2527d07c7e9cda2c6165d5edccf74752baac1b0 or later; rebuild and deploy updated kernel packages; for Ubuntu LTS users apply the corresponding dosfstools point releases only if they pull in the required kernel update; defer client driver loads until SMMU is bound via module parameters or initramfs ordering where patches cannot be applied immediately.

How to confirm the fix worked

Confirm kernel git describe contains c2527d07c7e9cda2c6165d5edccf74752baac1b0; reproduce probe sequence under concurrent load and verify absence of NULL dereference in arm_smmu_get_by_fwnode; inspect dmesg for successful iommu_device_register followed by driver_bound before client probes.

Typical attack path

1. Initiate SMMU device probe via really_probe
2. Immediately trigger client device probe via platform_dma_configure and of_iommu_configure
3. Hit window where driver_find_device returns before driver_bound
4. Dereference null smmu pointer in arm_smmu_probe_device
5. Crash kernel

How to detect it

Search kernel logs and crash dumps for arm_smmu_get_by_fwnode, next_device returning null, and the exact dereference comment 'null ptr assigned to smmu'; correlate with platform probe events around iommu_device_register; monitor for klist_next failures during early boot on affected ARM platforms.

• arm_smmu_get_by_fwnode
• null ptr assigned to smmu
• null ptr dereference while smmu->streamid_mask
• iommu_device_register.*really_probe

What your security team should do

• Patch ARM Linux kernels to fixed commit within 30 days given published date and ongoing kernel race exploitation trends
• Add kernel oops and arm_smmu null pointer signatures to SIEM alerting
• Test device probe ordering in staging environments before production rollout
• Review downstream dependent package counts and prioritize embedded/IoT fleets