CVE-2023-54140
Description
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuse
A syzbot stress test using a corrupted disk image reported that mark_buffer_dirty() called from __nilfs_mark_inode_dirty() or nilfs_palloc_commit_alloc_entry() may output a kernel warning, and can panic if the kernel is booted with panic_on_warn.
This is because nilfs2 keeps buffer pointers in local structures for some metadata and reuses them, but such buffers may be forcibly discarded by nilfs_clear_dirty_page() in some critical situations.
This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only"), but the issue has potentially existed before.
Fix this issue by checking the uptodate flag when attempting to reuse an internally held buffer, and reloading the metadata instead of reusing the buffer if the flag was lost.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A use-after-free-like bug in nilfs2 where reused metadata buffers can be discarded, causing a kernel warning or panic on corrupted disk images.
Root
Cause
In the Linux kernel's nilfs2 filesystem, a vulnerability exists in how metadata buffer pointers are cached and reused in local structures. When the filesystem encounters a corrupted disk image, certain critical operations (such as nilfs_clear_dirty_page()) can forcibly discard these cached buffers. If a subsequent call to mark_buffer_dirty() (via __nilfs_mark_inode_dirty() or nilfs_palloc_commit_alloc_entry()) attempts to) attempts to reuse a discarded buffer, the kernel triggers a WARNING and may panic if panic_on_warn` is set [1][2].
Attack
Surface
An attacker with the ability to mount a specially crafted corrupted nilfs2 image can trigger this condition without requiring any special privileges beyond the ability to mount a filesystem. The issue is exacerbated after commit 28a65b49eb53 ("nilfs2: do not write dirty data after degenerating to read-only"), but the underlying problem has existed for longer [1]. The attack surface is local; the attacker must be able to present a malicious disk image to the kernel.
Impact
Successful exploitation leads to a kernel WARNING and, if the system is configured with panic_on_warn, a full system panic (denial of service). No privilege escalation or data corruption beyond the filesystem itself is described.
Mitigation
The fix, applied in multiple stable kernel branches, adds a check for the uptodate flag on the cached buffer before reuse. If the flag is lost (indicating the buffer was discarded), the metadata is reloaded from disk instead of reusing the stale pointer [1][2][3][4]. Users should apply the relevant stable kernel update.
AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
9473795610594d95e4035887399a73016a5e1f1d637b63d8ab911bef132a04da07e958bfd46c11be2dca2b308b3eabc42cdaac8e7e5a0Vulnerability mechanics
Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
9- git.kernel.org/stable/c/46c11be2dca295742a5508ea910a77f7733fb7f4nvd
- git.kernel.org/stable/c/473795610594f261e98920f0945550314df36f07nvd
- git.kernel.org/stable/c/4da07e958bfda2d69d83db105780e8916e3ac02envd
- git.kernel.org/stable/c/99a73016a5e12a09586a96f998e91f9ea145cd00nvd
- git.kernel.org/stable/c/b308b3eabc429649b5501d36290cea403fbd746cnvd
- git.kernel.org/stable/c/b911bef132a06de01a745c6a24172d6db7216333nvd
- git.kernel.org/stable/c/cdaac8e7e5a059f9b5e816cda257f08d0abffacdnvd
- git.kernel.org/stable/c/d95e403588738c7ec38f52b9f490b15e7745d393nvd
- git.kernel.org/stable/c/f1d637b63d8a27ac3386f186a694907f2717fc13nvd
News mentions
0No linked articles in our index yet.