CVE-2024-26696

What it actually does

Race condition in nilfs2 allows nilfs_page_mkwrite() to skip waiting for writeback completion when the backing device does not require stable writes, enabling a folio to be dirtied while migrate_pages_batch() holds its lock, resulting in deadlock between the log writer thread in nilfs_lookup_dirty_data_buffers() and the migrating process.

Why it matters to the business

Unpatched kernels can experience filesystem-induced hangs that render the system unresponsive, require reboots, and risk metadata corruption or failed recovery after unclean shutdowns, disrupting workloads that rely on nilfs2.

How an attack unfolds

An attacker with local code execution triggers concurrent mbind() page migration and nilfs2 log writing; the conditional wait in nilfs_page_mkwrite() permits modification of a folio still under writeback, causing the log writer to block on the same locked folio and deadlock the system.

How to fix it

Upgrade the Linux kernel to the commit 228742b2ddfb99dfd71e5a307e6088ab6836272e or later stable releases that unconditionally wait for writeback in nilfs_page_mkwrite(); rebuild and reboot with the patched kernel; for systems that cannot immediately upgrade, avoid use of nilfs2 on devices without stable-write guarantees until patched.

How to confirm the fix worked

Confirm the running kernel contains commit 228742b2ddfb99dfd71e5a307e6088ab6836272e or an equivalent backport; exercise nilfs2 write and mbind workloads while monitoring for hangs; verify that nilfs_page_mkwrite() now always waits for writeback regardless of stable-write device flags.

Typical attack path

1. Obtain local execution on a system using nilfs2
2. Invoke mbind() or equivalent page-migration syscall on a mapped file
3. Simultaneously trigger nilfs2 log creation via writes or fsync
4. Exploit the missing writeback wait to dirty the folio during migration
5. Induce deadlock between migrate_pages_batch() and nilfs_lookup_dirty_data_buffers()

How to detect it

Review system logs for nilfs2 hang traces involving migrate_pages_batch and nilfs_lookup_dirty_data_buffers; inspect dmesg or kernel logs for deadlock indicators on nilfs2 mounts; correlate with processes performing mbind or memory migration on nilfs2 filesystems.

What your security team should do

• Prioritize kernel updates containing 228742b2ddfb99dfd71e5a307e6088ab6836272e on all nilfs2 deployments
• Add kernel version checks to asset inventory and block deployment of vulnerable kernels
• Monitor for nilfs2-related hangs in production workloads until remediation is complete
• Test patched kernels with migration and log-writing workloads before broad rollout