Skip to main content

Linux Kernel CVE-2026-43118

| EUVDEUVD-2026-27645 MEDIUM
2026-05-06 Linux
Information Disclosure Linux
5.5
CVSS 3.1 · NVD
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Create file and write data
  2. Delivery
    Truncate to zero and fsync
  3. Exploit
    Create hardlink and fsync
  4. Execution
    Trigger power failure
  5. Impact
    Log replay restores incorrect file size

Vulnerability Assessment

Exploitation Conditions

Exploitation requires all of the following conditions: (1) Filesystem using btrfs with transaction logging enabled (default configuration); (2) Local user with write access to the filesystem; (3) File that has been logged in full mode or created in a previous transaction; (4) Truncation to zero bytes with fsync; (5) Hardlink creation or file rename immediately after truncation; (6) Power failure, system crash, or unclean shutdown before the next filesystem sync. The vulnerability does not manifest under normal shutdown, and does not affect systems using ext4, XFS, or other filesystems. Requires Linux kernel versions before patched commits; not exploitable on patched kernels regardless of deployment.
Impact

CVSS 5.5 (local, low complexity, low privilege, no user interaction, high availability impact) combined with EPSS 0.02% (4th percentile) indicates this is a low-probability but real vulnerability affecting local users. The attack vector is local-only (AV:L) and requires low privilege (PR:L), meaning any local unprivileged user can trigger the condition through ordinary filesystem operations (truncate, fsync, hardlink). No active exploitation indicated by KEV status or POC availability. The real-world risk is limited to scenarios involving power failures or system crashes during the specific logging sequence, but when triggered, causes silent data corruption rather than system compromise. This is a data integrity issue, not a security issue in the traditional sense-it affects reliability rather than confidentiality, integrity, or availability of other users' data. EPSS low score reflects the narrow exploitation window and requirement for power failure.
Exploit ScenarioDerived

A local user with filesystem access creates a file, writes 64KB of data, syncs the filesystem, then truncates the file to zero bytes and fsyncs it. The user then creates a hardlink to the truncated file and fsyncs the directory. If a power failure or system crash occurs before the next sync, log replay after recovery will incorrectly restore the file to 64KB size instead of 0 bytes, silently corrupting the file. No special privileges or user interaction from other users is required.
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 – May 08, 2026

Data corruption in Linux kernel btrfs filesystem log replay allows local authenticated attackers to cause files to retain incorrect sizes after crash recovery. When a file is truncated to zero bytes, fssynced, and then a hardlink is created, the file incorrectly retains its pre-truncation size after a power failure and log replay, resulting in data integrity violation with availability impact.

RemediationAI

Apply the upstream Linux kernel patch available at git.kernel.org/stable/ commits fddb157536e67a055597f00a8b4922d5f5ed0826, 03e966b63df5b06790310c1faaf3e0cb43adea8b, or 5254d4181add9dfaa5e3519edd71cc8f752b2f85 depending on kernel branch. Users should upgrade to Linux 6.18.24, 6.19.14, or 7.0 or later where available. For systems using btrfs and unable to patch immediately, workarounds include disabling btrfs checksumming if data integrity can be verified through other means, or avoiding hardlinks and renames immediately after truncate operations followed by fsync. However, these workarounds reduce data protection and are not recommended-kernel upgrade is the proper remediation. The fix modifies fill_inode_item() to preserve real inode generation during logging and ensures correct i_size is logged for inodes created in previous transactions, with no expected side effects to normal filesystem operations.

Affected VersionsENISA

Linux patch: 7.0
Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <5254d4181add9dfaa5e3519edd71cc8f752b2f85
Linux patch: 6.18.24
Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <fddb157536e67a055597f00a8b4922d5f5ed0826
Linux 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <03e966b63df5b06790310c1faaf3e0cb43adea8b
Linux patch: 6.19.14

Affects your stack

Find out whether the stacks and servers you run are on an affected version.

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 exists in the btrfs filesystem's transaction log (journal) replay mechanism, specifically in the fill_inode_item() and overwrite_item() functions. When logging inode existence without full extent data (LOG_INODE_EXISTS mode), the kernel sets generation to 0 as a signal to skip i_size updates during replay. However, when an inode is first logged in full mode with i_size=0 and subsequently logged in exists mode (e.g., during hardlink creation), the generation remains 0 while i_size is 0, causing the replay logic to incorrectly preserve the old i_size instead of updating it. The fix ensures the real generation is logged when an inode was modified in the current transaction and ensures correct i_size is logged for inodes created in previous transactions. CWE data not provided in source materials.

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 MEDIUM

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 08, 2026 - 17:37 NVD
5.5 (MEDIUM)
Patch available
May 06, 2026 - 11:31 EUVD
CVE Published
May 06, 2026 - 07:40 nvd
MEDIUM 5.5

DescriptionNVD

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

btrfs: fix zero size inode with non-zero size after log replay

When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents).

This works fine except when we have already logged an inode in full mode or it's the first time we are logging an inode created in a past transaction, that inode has a new i_size of 0 and then we log a new name for the inode (due to a new hardlink or a rename), in which case we log an i_size of 0 for the inode and a generation of 0, which causes the log replay code to not update the inode's i_size to 0 (in overwrite_item()).

An example scenario:

mkdir /mnt/dir xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo

sync

xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo

ln /mnt/dir/foo /mnt/dir/bar

xfs_io -c "fsync" /mnt/dir

<power fail>

After log replay the file remains with a size of 64K. This is because when we first log the inode, when we fsync file foo, we log its current i_size of 0, and then when we create a hard link we log again the inode in exists mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we add to the log tree, so during log replay overwrite_item() sees that the generation is 0 and i_size is 0 so we skip updating the inode's i_size from 64K to 0.

Fix this by making sure at fill_inode_item() we always log the real generation of the inode if it was logged in the current transaction with the i_size we logged before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log the i_size stored in the inode item located from the commit root, so that if we log multiple times that the inode exists we get the correct i_size.

A test case for fstests will follow soon.

Threat Intelligence Overview

EPSS Score
0.0%
Top 96% exploitable
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS MSRC 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-43118 ADVISORY https://vuldb.com/vuln/361310 REF https://git.kernel.org/stable/c/03e966b63df5b06790310c1faaf3e0cb43adea8b REF https://git.kernel.org/stable/c/126999610eddeb1de3b47680585f4bc9531dc7f4 REF https://git.kernel.org/stable/c/5254d4181add9dfaa5e3519edd71cc8f752b2f85 REF https://git.kernel.org/stable/c/91990732ec4ce5c09361d498c6d621f5a76ee1f2 REF https://git.kernel.org/stable/c/c939bfa67d221f75351a5bf2fc912e8125547b7e REF https://git.kernel.org/stable/c/fddb157536e67a055597f00a8b4922d5f5ed0826

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