CVE-2024-57984

What it actually does

Race condition in dw_i3c_master allows use-after-free when dw_i3c_common_remove unregisters the device and frees master->base while a pending dw_i3c_hj_work still executes i3c_master_do_daa on that freed structure.

Why it matters to the business

Systems relying on the DesignWare I3C controller risk kernel crashes or memory corruption during driver unload, raising denial-of-service exposure on servers and embedded devices with high downstream prevalence.

How an attack unfolds

An attacker triggers an interrupt that queues dw_i3c_hj_work, then forces module removal so that dw_i3c_common_remove performs device_unregister while the work item later dereferences the already-freed master base.

How to fix it

Cancel the hj_work before unregistering in dw_i3c_common_remove; apply the upstream fix or update to a kernel containing the resolution.

How to confirm the fix worked

Inspect dw_i3c_common_remove for explicit work cancellation, then exercise repeated module load/unload cycles under interrupt load to confirm absence of UAF.

Typical attack path

1. Trigger dw_i3c_master_irq_handler to schedule dw_i3c_hj_work
2. Initiate dw_i3c_common_remove to call i3c_master_unregister and device_release
3. Allow the delayed work to invoke i3c_master_do_daa on the freed base

How to detect it

Review kernel logs for oops/panic traces mentioning dw_i3c_hj_work or i3c_master_do_daa during module removal; correlate with audit records of dw_i3c_common_remove calls.

What your security team should do

• Apply the kernel fix immediately given the 608-day exposure window
• Audit all systems using DesignWare I3C hardware for the vulnerable driver
• Harden module unload paths with additional locking or refcounting