CVE-2024-49874

What it actually does

Use-after-free in the Linux kernel svc_i3c_master driver where work items (hj_work, ibi_work) access master->base after it is freed during module removal due to missing cancellation of scheduled works before i3c_master_unregister.

Why it matters to the business

Kernel-level memory corruption on systems using the affected I3C controller driver can lead to crashes, denial of service, or potential privilege escalation; low urgency given no KEV listing or ransomware use and stable low EPSS.

How an attack unfolds

An attacker with local access triggers concurrent execution of svc_i3c_master_hj_work or svc_i3c_master_ibi_work while svc_i3c_master_remove runs, allowing the work handler to dereference the already-freed master structure during i3c_master_do_daa.

How to fix it

Update to a kernel containing the fix that cancels hj_work and ibi_work before calling i3c_master_unregister in svc_i3c_master_remove; apply the patch or newer mainline release that addresses the race.

How to confirm the fix worked

Confirm the work cancel calls exist in svc_i3c_master_remove and that module unload no longer produces use-after-free reports under concurrent IRQ or work scheduling; retest with dynamic analysis tools for the driver.

Typical attack path

1. Obtain local code execution or module-loading privileges on a vulnerable kernel
2. Unload the svc_i3c_master module to invoke remove path
3. Race the work scheduler and cleanup to hit the freed object
4. Leverage resulting UAF for memory corruption or information leak

How to detect it

Review kernel logs for use-after-free warnings or slab corruption involving i3c structures during module unload; inspect dmesg and crash dumps for references to svc_i3c_master_hj_work or i3c_master_do_daa after device_unregister.

What your security team should do

• Prioritize kernel updates on systems exposing the svc_i3c_master driver
• Monitor for local privilege-escalation attempts until patched
• Restrict unprivileged module loading where feasible