Skip to main content

Linux EUVDEUVD-2026-18731

| CVE-2026-23465 MEDIUM
2026-04-03 Linux GHSA-wm46-26gp-9px3
Information Disclosure Linux
5.5
CVSS 3.1 · NVD
View

Vulnerability Assessment

Impact

This is a data loss vulnerability with moderate real-world risk. Although no CVSS score or exploitation metrics are provided, the impact is objective: silent data loss (missing files and directories after recovery) following system crash. The attack vector is indirect-no remote or privileged code execution is possible. Exploitation requires either intentional filesystem manipulation (creating the specific conflicting inode scenario) or accidental reproduction through normal filesystem operations followed by unexpected power loss. The vulnerability is not exploitable in a traditional security threat model (no privilege escalation, code execution, or information disclosure of sensitive data), but rather represents a data integrity bug. Systems using btrfs actively, particularly those prone to power disruptions or running workloads with frequent fsync operations, face elevated risk. The fact that five kernel commits address this issue (across different stable branches) indicates this was treated as a legitimate defect requiring urgent backport, not a security exploit vector. Real-world risk is contingent on btrfs adoption (many distributions default to ext4 or other filesystems) and uncontrolled shutdown scenarios.
Exploit ScenarioDerived

A system user (or application) repeatedly creates and deletes directories, then creates new files or subdirectories with names previously associated with deleted directories. When the newly created sibling directory is fsync'd (e.g., via explicit xfs_io fsync or application-level sync), the kernel logs the parent directory but omits the new child directory entries. A subsequent explicit fsync on the parent directory becomes a no-op since the kernel already logged it incompletely. If an unplanned power loss or system crash occurs before the filesystem is cleanly unmounted, the transaction log replay will restore the parent directory inode but omit the missing child entries, resulting in data loss visible only after recovery. This scenario is reproducible on demand on vulnerable kernels and does not require privilege escalation or remote access-only filesystem write access and ability to trigger power loss or system crash.
This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Apr 03, 2026

Linux kernel btrfs filesystem fails to log new directory dentries when the parent directory of a conflicting inode is logged, causing new files and subdirectories to become inaccessible after power failure or system crash. The vulnerability affects all Linux kernel versions with btrfs; an attacker or system malfunction can trigger data loss through specific filesystem operation sequences involving deleted and recreated inodes with naming conflicts.

RemediationAI

The primary remediation is kernel upgrade to a version including the btrfs dentry logging fix. Patch commits are available in Linux stable kernel branches; systems should update to the latest stable kernel release for their branch (e.g., 5.10.x, 5.15.x, 6.1.x, or 6.6.x stable series where the fix has been backported). Users should verify their distribution's kernel release notes to confirm the fix is included. Until a patched kernel is deployed, users relying on btrfs should avoid the specific scenario described (directory deletion, inode number reuse via file creation, and fsync operations) if possible, and ensure reliable power management to minimize crash scenarios. Systems using alternative filesystems (ext4, xfs, etc.) are not affected. Critical data on btrfs volumes should be validated after any unplanned shutdown to detect silent data loss. References: kernel stable commits at https://git.kernel.org/stable/c/ with commit hashes listed above.

Affected VersionsENISA

Linux a3baaf0d786e22fc86295fda9c58ba0dee07599f <6f5a51969b1deb79aefd2194b48fe7e78e72ff7e
Linux patch: 6.18.20
Linux 5.1
Linux patch: 6.6.130
Linux a3baaf0d786e22fc86295fda9c58ba0dee07599f <1cf30c73602c69d750c9345c47f2c0e9d0cfb578
Linux patch: 6.12.78
Linux patch: 7.0-rc5
Linux a3baaf0d786e22fc86295fda9c58ba0dee07599f <9573a365ff9ff45da9222d3fe63695ce562beb24
Linux patch: 0
Linux patch: 6.19.10
Linux a3baaf0d786e22fc86295fda9c58ba0dee07599f <f556b1e09d054e31f464c0fd37280c2b5a393fee
Linux a3baaf0d786e22fc86295fda9c58ba0dee07599f <56e72c8b02d982be775d9df025357c152383ee84

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Sign in to check
Technical ContextAI · show details

The vulnerability resides in the btrfs (B-tree file system) implementation within the Linux kernel's logging mechanism for fsync operations. Btrfs maintains a transaction log to ensure filesystem consistency after unexpected shutdowns. When a directory inode conflicts with a previously deleted inode of the same name, the kernel's logging code would mark the parent directory inode as logged without recording its new dentries (directory entries). This occurs at the intersection of inode conflict resolution and transaction log management. The root cause is incomplete dentry logging in the conflicting inode handling path-specifically, when a deleted directory's inode number is reused by a new file, the parent directory logging skips recording child directory entries that should persist across power failures. The CPE cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:* indicates all Linux kernel versions are potentially affected, though the fix is targeted at btrfs-specific code paths.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources
Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

NVD PRIMARY 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE MEDIUM
Red Hat 5.5 LOW

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
CVSS changed
May 20, 2026 - 15:22 NVD
5.5 (MEDIUM)
Patch available
Apr 16, 2026 - 05:29 EUVD
6f5a51969b1deb79aefd2194b48fe7e78e72ff7e,1cf30c73602c69d750c9345c47f2c0e9d0cfb578,9573a365ff9ff45da9222d3fe63695ce562beb24
CVE Published
Apr 03, 2026 - 15:15 nvd
N/A

DescriptionNVD

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.

Threat Intelligence Overview

EPSS Score
0.0%
Top 95% exploitable
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vendor VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact· derived
Medium

Priority Score

28
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +28
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2025-68613 HIGH POC
8.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-23465 ADVISORY https://ubuntu.com/security/notices/USN-8567-1 ADVISORY https://vuldb.com/vuln/355164 REF https://git.kernel.org/stable/c/1cf30c73602c69d750c9345c47f2c0e9d0cfb578 REF https://git.kernel.org/stable/c/56e72c8b02d982be775d9df025357c152383ee84 REF https://git.kernel.org/stable/c/6c23595c54cfeb878e3fbbb8eb08bc5061d0c2d4 REF https://git.kernel.org/stable/c/6f5a51969b1deb79aefd2194b48fe7e78e72ff7e REF https://git.kernel.org/stable/c/9573a365ff9ff45da9222d3fe63695ce562beb24 REF https://git.kernel.org/stable/c/f556b1e09d054e31f464c0fd37280c2b5a393fee

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy