CVE-2024-36923

What it actually does

Use of uninitialized memory references (such as fscache cookies) during inode eviction in the 9p filesystem when an iget operation fails and leaves the inode only partially initialized.

Why it matters to the business

Systems using the 9p network filesystem may experience kernel instability, crashes, or unexpected behavior during error recovery from server communication failures, potentially affecting availability of file services in Linux environments.

How an attack unfolds

An attacker with the ability to trigger or simulate iget failures (for example by controlling responses from a 9p server) can cause a partially initialized inode to be evicted, leading the kernel to dereference uninitialized structures and resulting in memory corruption or crashes.

How to fix it

Update the Linux kernel to version 6.1.119 or later, or apply the commit 18cf7026355187b8d2b4cdfed61dbf873e9d29ff in the stable tree; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the running kernel version is at or above the fixed release; review dmesg or kernel logs after inducing 9p iget failure scenarios to verify no uninitialized structure references occur.

Typical attack path

1. Establish or control a 9p server connection to a target Linux system
2. Induce an iget failure by returning incomplete or erroneous inode metadata
3. Trigger inode eviction on the client
4. Cause the kernel to access uninitialized fscache or other structures during cleanup

How to detect it

Review kernel logs for oops or warnings referencing 9p inode eviction, fscache cookies, or bad_inode checks around the time of 9p mount or iget failures; correlate with system events that involve 9p server communication errors.

What your security team should do

• Prioritize kernel updates on all systems exposing 9p mounts
• Monitor for kernel oops or panics involving 9p inode eviction
• Limit use of 9p filesystems to trusted networks until patched