CVE-2024-46781

What it actually does

Use-after-free in nilfs2 mount-time recovery: inodes recovered from partial dsync logs remain on ns_dirty_files list and are not freed if an error occurs before the log writer creates a recovered checkpoint.

Why it matters to the business

Kernel memory corruption or crashes on systems using the nilfs2 filesystem during recovery scenarios; potential denial of service or escalation paths in affected Linux environments, though exploitation is not observed in the wild.

How an attack unfolds

An attacker with ability to influence filesystem state or trigger mount-time recovery with partial logs from dsync writes can cause the recovery routine to fail midway, leaving dangling inodes that lead to use-after-free when accessed later.

How to fix it

Update the Linux kernel to a version containing commit 35a9a7a7d94662146396199b0cfd95f9517cdd14 or later; apply the cleanup of recovered inodes on recovery failure path.

How to confirm the fix worked

Verify kernel source contains the fix commit; confirm ns_dirty_files cleanup occurs on early recovery errors; run mount/recovery tests with error injection and KASAN enabled.

Typical attack path

1. Prepare or corrupt a nilfs2 volume containing partial logs from dsync writes
2. Trigger mount operation that initiates rollforward recovery
3. Inject or encounter an error before the log writer starts
4. Trigger subsequent access to the unfreed inodes to exploit the use-after-free

How to detect it

Inspect kernel logs for KASAN use-after-free reports referencing nilfs2 recovery or ns_dirty_files; correlate with mount operations on nilfs2 volumes and partial log recovery attempts.

• KASAN: use-after-free in nilfs
• nilfs_dirty_files
• nilfs2 rollforward recovery error

What your security team should do

• Prioritize kernel updates for systems using nilfs2
• Review filesystem mount and recovery logging for nilfs2 volumes
• Test error paths in recovery routines in staging environments
• Monitor for future nilfs2 or kernel UseAfterFree reports