CVE-2024-39494

What it actually does

Use-after-free on a dentry's d_name.name in IMA code paths because rename can free the prior name without any of the stabilizing locks (d_lock, parent d_lock, parent i_rwsem exclusive, rename_lock) being held at the access sites.

Why it matters to the business

Local attackers on Linux systems using IMA may trigger kernel memory corruption leading to crashes or privilege escalation; low immediate risk given stable EPSS and no KEV listing, but still requires prompt kernel updates across fleets.

How an attack unfolds

An attacker with local access performs filesystem rename operations that cause IMA to access a freed dentry name buffer; the race is triggered when the name snapshot is not taken before the rename frees the old value.

How to fix it

Update the Linux kernel to the commit 480afcbeb7aaaa22677d3dd48ec590b441eaac1a or later stable releases that contain the fix; rebuild and deploy the updated kernel image.

How to confirm the fix worked

Verify the running kernel contains commit 480afcbeb7aaaa22677d3dd48ec590b441eaac1a; inspect IMA-related dentry name handling code for the stable snapshot change.

Typical attack path

1. Obtain local user access on a Linux system with IMA enabled
2. Trigger rename operations on files monitored by IMA
3. Cause IMA dentry name access after the rename frees the prior name buffer
4. Exploit the resulting use-after-free for memory corruption or code execution

How to detect it

Review kernel logs for IMA-related warnings or oops involving dentry names; correlate with filesystem rename activity on monitored paths; examine crash dumps for use-after-free signatures in IMA code.

What your security team should do

• Prioritize kernel updates on systems with IMA enabled
• Monitor for new stable releases containing the referenced commit
• Test updated kernels in staging before broad deployment
• Review IMA usage and consider disabling if not required until patched