CVE-2024-56620

What it actually does

NULL pointer dereference during platform MSI teardown in ufs_qcom_remove when ESI is disabled, triggered on driver detach or module unload.

Why it matters to the business

Kernel panic or system instability on Qualcomm UFS-equipped devices during driver removal or module unload operations; low exploitation likelihood reduces immediate risk but still requires patching for stability.

How an attack unfolds

An attacker with local access unloads the ufs_qcom module or detaches the driver, causing the remove path to call platform_device_msi_free_irqs_all without prior ESI-enabled MSI allocation, resulting in the NULL dereference.

How to fix it

Update the Linux kernel to commit f16a097047e38dcdd169a15e3eed1b2f2147a2e7 or later stable release containing the fix that guards MSI free behind ESI enablement check.

How to confirm the fix worked

Confirm kernel version includes the guard in ufs_qcom_remove; attempt driver detach or module removal in a test environment and verify no NULL dereference crash occurs.

Typical attack path

1. Obtain local access on affected Linux system with ufs_qcom driver
2. Trigger module unload via rmmod or driver detach
3. ufs_qcom_remove executes and calls platform_device_msi_free_irqs_all unconditionally
4. NULL pointer dereference occurs leading to kernel panic

How to detect it

Review kernel logs for NULL pointer dereference traces involving ufs_qcom_remove and platform_device_msi_free_irqs_all; inspect module unload events via auditd or dmesg around crash times.

What your security team should do

• Apply the referenced kernel commit or distribution update immediately on affected Qualcomm UFS systems
• Monitor for any local module unload attempts in high-value environments
• Prioritize testing on Qualcomm-based embedded or mobile Linux deployments