Skip to content
Fencer Vulns
medium 5.5

CVE-2026-43118 json

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

published 2026-05-06 6 mo ago modified 2026-10-30 10 d ago also EUVD-2026-27645

cvss
5.5
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 4%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 6.1.191, 6.6.160, 6.12.114, 6.18.24, 6.19.14, 7.0
  • linux Debian 13 6.12.115-2
  • linux Debian 14 6.19.14-1

debian advisories DEBIAN-CVE-2026-43118

  • kernel-source Linux Micro 6.1, Linux Micro 6.0 6.4.0-51.1
  • kernel-default Linux Micro 6.1, Linux Micro 6.0 6.4.0-51.1
  • kernel-kvmsmall Linux Micro 6.1, Linux Micro 6.0 6.4.0-51.1
  • kernel-rt Linux Micro 6.1, Linux Micro 6.0 6.4.0-51.1
  • kernel-source-rt Linux Micro 6.1, Linux Micro 6.0 6.4.0-51.1
  • kernel-default SLES 16.0, SLE High Availability Extension 16.0, Linux Micro 6.2 +1 more 6.12.0-160000.37.1
  • kernel-rt Linux Micro 6.2 6.12.0-160000.37.1
  • kernel-64kb SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.37.1

suse advisories SUSE-SU-2026:23244-1SUSE-SU-2026:23241-1SUSE-SU-2026:23194-1SUSE-SU-2026:23193-1SUSE-SU-2026:23237-1SUSE-SU-2026:23068-1

  • kernel-rt openSUSE Leap 16.0 6.12.0-160000.37.1
  • dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.37.1
  • kernel-64kb openSUSE Leap 16.0 6.12.0-160000.37.1
  • kernel-syms openSUSE Leap 16.0 6.12.0-160000.37.1
  • kernel-azure openSUSE Leap 16.0 6.12.0-160000.37.1
  • kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.37.1
  • kernel-source openSUSE Leap 16.0 6.12.0-160000.37.1
  • kernel-default openSUSE Leap 16.0 6.12.0-160000.37.1

opensuse advisories openSUSE-SU-2026:21555-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-43118 updated cvss 5.5

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

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: workaround, no fix planned “To mitigate this issue, prevent the btrfs module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 10 kernel
    affected: workaround, no fix available “To mitigate this issue, prevent the btrfs module from being loaded. See https://access.redhat.com/solutions/41278 for instructions.”
  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.16% chance of exploitation in the next 30 days, higher than 4% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.