CVE-2026-23465
Last modified
CVE-2026-23465 is a medium-severity vulnerability rated 5.5/10 on the CVSS scale. 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.. EPSS estimates a 0.12% chance of exploitation in the next 30 days.
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.
Metrics
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Affected Software
| Vendor | Product | Versions | Update |
|---|---|---|---|
| Linux | Linux Kernel | >= 5.1, < 6.6.130 | — |
| Linux | Linux Kernel | >= 6.7, < 6.12.78 | — |
| Linux | Linux Kernel | >= 6.13, < 6.18.20 | — |
| Linux | Linux Kernel | >= 6.19, < 6.19.10 | — |
| Linux | Linux Kernel | 7.0 | Rc1 |
References
Timeline
- Published
- Last Modified
- Status
- Analyzed
Frequently Asked Questions
What is CVE-2026-23465?
How severe is CVE-2026-23465?
How do I fix CVE-2026-23465?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-2346Authorization bypass through User-Controlled key vulnerabili…9.8
- CVE-2026-23460In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-23461In the Linux kernel, the following vulnerability has been re…8.8
- CVE-2026-23462In the Linux kernel, the following vulnerability has been re…8.8
- CVE-2026-23463In the Linux kernel, the following vulnerability has been re…4.7
- CVE-2026-23464In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-23466In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-23467In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-23468In the Linux kernel, the following vulnerability has been re…5.5
- CVE-2026-23469In the Linux kernel, the following vulnerability has been re…4.7
- CVE-2026-2347Authorization bypass through User-Controlled key vulnerabili…9.8
- CVE-2026-23470In the Linux kernel, the following vulnerability has been re…5.5
Are you affected by CVE-2026-23465?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
