Description
In the Linux kernel, the following vulnerability has been resolved:

btrfs: log new dentries when logging parent dir of a conflicting inode

If we log the parent directory of a conflicting inode, we are not logging
the new dentries of the directory, so when we finish we have the parent
directory's inode marked as logged but we did not log its new dentries.
As a consequence if the parent directory is explicitly fsynced later and
it does not have any new changes since we logged it, the fsync is a no-op
and after a power failure the new dentries are missing.

Example scenario:

$ mkdir foo

$ sync

$rmdir foo

$ mkdir dir1
$ mkdir dir2

# A file with the same name and parent as the directory we just deleted
# and was persisted in a past transaction. So the deleted directory's
# inode is a conflicting inode of this new file's inode.
$ touch foo

$ ln foo dir2/link

# The fsync on dir2 will log the parent directory (".") because the
# conflicting inode (deleted directory) does not exists anymore, but it
# it does not log its new dentries (dir1).
$ xfs_io -c "fsync" dir2

# This fsync on the parent directory is no-op, since the previous fsync
# logged it (but without logging its new dentries).
$ xfs_io -c "fsync" .

<power failure>

# After log replay dir1 is missing.

Fix this by ensuring we log new dir dentries whenever we log the parent
directory of a no longer existing conflicting inode.

A test case for fstests will follow soon.
Published: 2026-04-03
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Data loss
Action: Patch
AI Analysis

Impact

In the btrfs filesystem, the kernel fails to log new directory entries when it logs the parent directory of a conflicting inode. If the parent directory is later fsynced, the filesystem records it as up‑to‑date without recording those new entries. After a power failure, the log replay restores the filesystem but the missing entries are never recreated, leading to disappearance of directories or files and resulting in data loss or corruption. This defect relates to CWE‑821, which concerns improper control over the order in which resources are processed. While the vulnerability does not provide remote code execution, it can be triggered by a local or privileged user who creates new files or directories, then performs an explicit fsync on a parent directory, and subsequently forces a power failure. The lack of an active exploit record and absence from CISA’s KEV list suggest current exploitation is limited but the risk remains moderate. The CVSS score of 5.5 places the issue in the medium severity range, and the lack of EPSS data means its exploitation likelihood cannot be quantified. Nonetheless, because the bug can permanently remove filesystem entries, it poses a tangible threat to data integrity.

Affected Systems

Linux kernel implementations that use the btrfs filesystem are affected. The vulnerability applies to any distribution shipping a kernel that contains the buggy btrfs code. No specific kernel versions are listed, so all current kernels that have not yet received the patch may be vulnerable.

Risk and Exploitability

The medium CVSS score, absence from the KEV catalog, and the need for localized control (creating new entries, fsyncing a parent directory, and causing a power loss) make exploitation limited to local or privileged attackers. No public exploits have been reported. Nevertheless, the potential for permanent data loss warrants timely remediation.

Generated by OpenCVE AI on April 4, 2026 at 03:43 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the btrfs logging fix
  • If an immediate kernel update is unavailable, avoid performing explicit fsync on directories that contain newly created entries until the kernel is patched
  • Back up critical data regularly to recover from possible inode loss
  • Monitor vendor release notes for updates addressing the btrfs logging issue

Generated by OpenCVE AI on April 4, 2026 at 03:43 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 04 Apr 2026 01:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-821
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Fri, 03 Apr 2026 16:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, but it # it does not log its new dentries (dir1). $ xfs_io -c "fsync" dir2 # This fsync on the parent directory is no-op, since the previous fsync # logged it (but without logging its new dentries). $ xfs_io -c "fsync" . <power failure> # After log replay dir1 is missing. Fix this by ensuring we log new dir dentries whenever we log the parent directory of a no longer existing conflicting inode. A test case for fstests will follow soon.
Title btrfs: log new dentries when logging parent dir of a conflicting inode
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-04-13T06:07:59.882Z

Reserved: 2026-01-13T15:37:46.021Z

Link: CVE-2026-23465

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-04-03T16:16:33.850

Modified: 2026-04-07T13:20:55.200

Link: CVE-2026-23465

cve-icon Redhat

Severity : Low

Publid Date: 2026-04-03T00:00:00Z

Links: CVE-2026-23465 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-04-07T07:17:13Z

Weaknesses