Skip to main content

Linux CVE-2026-23465

| EUVDEUVD-2026-18731 MEDIUM
2026-04-03 Linux GHSA-wm46-26gp-9px3
5.5
CVSS 3.1 · NVD
Share

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
qualitative
Red Hat
5.5 LOW
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
CVSS changed
May 20, 2026 - 15:22 NVD
5.5 (MEDIUM)
Patch available
Apr 16, 2026 - 05:29 EUVD
6f5a51969b1deb79aefd2194b48fe7e78e72ff7e,1cf30c73602c69d750c9345c47f2c0e9d0cfb578,9573a365ff9ff45da9222d3fe63695ce562beb24
EUVD ID Assigned
Apr 03, 2026 - 15:30 euvd
EUVD-2026-18731
Analysis Generated
Apr 03, 2026 - 15:30 vuln.today
CVE Published
Apr 03, 2026 - 15:15 nvd
N/A

DescriptionCVE.org

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.

AnalysisAI

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.

Technical ContextAI

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.

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.

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

Share

CVE-2026-23465 vulnerability details – vuln.today

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