CVE-2024-39463

What it actually does

Use-after-free on dentry's d_fsdata fid list in the 9p filesystem when a thread looks up a fid through dentry while another thread unlinks it, due to missing d_lock protection around access in v9fs_fid_find and v9fs_dentry_release.

Why it matters to the business

Kernel crashes or potential privilege escalation in systems using the 9p filesystem, increasing risk of downtime or full host compromise; high prevalence in Linux environments amplifies exposure despite low EPSS.

How an attack unfolds

An attacker triggers concurrent v9fs operations (lookup during unlink) to cause refcount underflow on a fid, leading to use-after-free; listed threat actors targeting kernel issues could adapt this for local RCE chains.

How to fix it

Apply the upstream fix moving the hlist under d_lock; for affected mattermost/mattermost (GIT) deployments upgrade to one of: 45093ef4be396d39748078f9205a88ba5756e0b9 or 51fdf7ee51c379a80fe852f24f69e463386581d3.

How to confirm the fix worked

Confirm kernel version includes the dentry locking change; test concurrent getattr and unlink operations on 9p mounts; verify fixed commits are present in mattermost/mattermost (GIT) builds.

Typical attack path

1. Obtain local access or trigger 9p filesystem operations
2. Race v9fs_fid_lookup_with_uid against v9fs_remove to hit the unlocked fid list
3. Trigger p9_fid_get on the freed object to cause UAF
4. Escalate via kernel memory corruption

How to detect it

Review kernel logs for refcount_t addition on 0 warnings, v9fs_fid_find stack traces, or UAF reports involving p9_fid_get and v9fs_dentry_release; correlate with threat actor activity on kernel vulnerabilities.

What your security team should do

• Prioritize patching Linux kernels using 9p within 30 days given published date and any Android kernel exploit context
• Monitor for 9p-related crashes in logs
• Restrict 9p mounts to trusted sources until upgraded