Cloudanix VulnDB

CVE-2025-21722

None

CVSS

—

EPSS

0.3%

Published

Feb 27, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how Linux handles certain storage operations on damaged filesystems could let an attacker crash the machine or potentially run code with full system privileges.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Buffer head state inconsistencies arise in nilfs2 when filesystem corruption triggers read-only fallback, causing mark_buffer_dirty and btree propagation callbacks to force-clear folio states on still-referenced buffers and enabling use-after-free.

Why it matters to the business

Systems using the nilfs2 filesystem face elevated risk of kernel crashes or memory corruption on corrupted volumes; the issue affects a niche but widely deployed Linux filesystem with low observed exploitation activity.

How an attack unfolds

An attacker first corrupts nilfs2 metadata to force read-only fallback, then issues directory or file creation operations that invoke allocation and btree propagation paths; the callbacks then clear active buffer states, leading to subsequent dereference of freed buffer heads.

How to fix it

Update the Linux kernel to a version containing commit 7d0544bacc11d6aa26ecd7debf9353193c7a3328 or later; rebuild and reboot with the patched kernel image.

How to confirm the fix worked

Confirm the running kernel contains commit 7d0544bacc11d6aa26ecd7debf9353193c7a3328 via git describe or uname output; attempt nilfs2 corruption scenarios in a test environment and verify absence of the warnings in fs/buffer.c and fs/nilfs2/btree.c.

Typical attack path

  1. Trigger or plant filesystem corruption to activate nilfs2 read-only fallback
  2. Perform mkdir or similar metadata operations that call nilfs_new_inode and nilfs_palloc_commit_alloc_entry
  3. Invoke btree propagation during segment construction to hit the inconsistent buffer state
  4. Trigger use-after-free on the cleared buffer head

How to detect it

Search kernel logs for the specific WARNINGs at fs/buffer.c:1177 and fs/nilfs2/btree.c:2089 occurring after nilfs2 read-only fallback; inspect crash dumps for freed buffer_head objects referenced from nilfs_palloc or btree paths.

What your security team should do

  • Prioritize kernel upgrade on any system mounting nilfs2 volumes
  • Monitor for nilfs2 read-only fallback events in system logs
  • Apply the fix even on systems without active KEV listing due to the use-after-free nature

The record

In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series "nilfs2: protect busy buffer heads from being force-cleared". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 linux 0 No fix
Debian:11 linux-6.1 0 6.1.129-1~deb11u1
Debian:12 linux 0 No fix
Debian:13 linux 0 No fix
Debian:13 linux 0 6.12.13-1
Linux Kernel 3.10.0 5.4.291

Related vulnerabilities