VulnerabilityPublished 6 May 2026Updated 21 Oct 2026

CVE-2026-43118: Linux kernel · btrfs: fix zero size inode with non-zero size after log replay

Affects Linux kernelSource CVE Database V5

Not known to be exploited · fixed in fddb157536e67a055597f00a8b4922d5f5ed0826 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 17:30 UTC

Severity

Unrated

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 4% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in fddb157536e67a055597f00a8b4922d5f5ed0826, c939bfa67d221f75351a5bf2fc912e8125547b7e, 91990732ec4ce5c09361d498c6d621f5a76ee1f2 +2

Exploitation evidence

Disclosed: evidence found.
CVE published 6 May 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 12fcfd22fe5bf4fe74710232098bc101af497995, < fddb157536e67a055597f00a8b4922d5f5ed0826	Fixed in fddb157536e67a055597f00a8b4922d5f5ed0826
LinuxLinux	Affected ≥ 12fcfd22fe5bf4fe74710232098bc101af497995, < c939bfa67d221f75351a5bf2fc912e8125547b7e	Fixed in c939bfa67d221f75351a5bf2fc912e8125547b7e
LinuxLinux	Affected ≥ 12fcfd22fe5bf4fe74710232098bc101af497995, < 91990732ec4ce5c09361d498c6d621f5a76ee1f2	Fixed in 91990732ec4ce5c09361d498c6d621f5a76ee1f2
LinuxLinux	Affected ≥ 12fcfd22fe5bf4fe74710232098bc101af497995, < 5254d4181add9dfaa5e3519edd71cc8f752b2f85	Fixed in 5254d4181add9dfaa5e3519edd71cc8f752b2f85
LinuxLinux	Affected ≥ 12fcfd22fe5bf4fe74710232098bc101af497995, < 03e966b63df5b06790310c1faaf3e0cb43adea8b	Fixed in 03e966b63df5b06790310c1faaf3e0cb43adea8b
LinuxLinux	Affected =2.6.30	Fixed in–

Description

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.

References

Community reviews

Loading reviews…