CVE-2026-43365
HighCVSS 8.2Exploitation Probability (EPSS)
Low risk47th percentile - higher than 47% of all known CVEs
Summary
A vulnerability in the Linux kernel's XFS filesystem causes incorrect l_iclog_roundoff values (512 instead of expected 4096) when the superblock lacks a log stripe unit, leading to corrupted logs and unmountable filesystems. This occurs on disks with 4k physical sectors.
Risk Assessment
This can result in data loss or filesystem unavailability after a crash or improper mount, especially on disks with 4k sectors.
Recommendation
Update the Linux kernel to a version containing the fix, or avoid using XFS filesystems created by broken mkfs on 4k-sector disks until patched.
Other vulnerabilities in Linux kernel XFS
See all- CVE-2026-98975High
In the Linux kernel, XFS exchange-range operations incorrectly moved the reflink flag between files even though a file can still own shared blocks beyond i_disk_size. This caused in-place writes instead of CoW, corrupting the other file sharing those blocks. The fix stops moving the flags and sets them on both inodes, including for XFS_IOC_SWAPEXT.
- CVE-2026-98974High
A bug was fixed in the Linux kernel's XFS involving the XFS_IOC_EXCHANGE_RANGE operation with the TO_EOF flag. Incorrect swapping of file sizes at nonzero offsets caused a file to have shared blocks beyond EOF, and subsequently the reflink flag was incorrectly cleared, allowing a shared block to be overwritten.
- CVE-2026-97549Low risk· EPSS 9%
A vulnerability in the Linux kernel's XFS filesystem causes under-reservation of blocks when repairing shortform directories. Incorrectly setting args->total to 1 instead of the actual directory block count (fsbcount) triggers an assertion failure and can lead to a filesystem shutdown.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. This leads to corrupt logs and unmountable filesystems in generic/617 on a disk with 4k physical sectors... XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Torn write (CRC failure) detected at log block 0x318e. Truncating head block from 0x3197. XFS (sda1): failed to locate log tail XFS (sda1): log mount/recovery failed: error -74 XFS (sda1): log mount failed XFS (sda1): Mounting V5 Filesystem ff3121ca-26e6-4b77-b742-aaff9a449e1c XFS (sda1): Ending clean mount ...on the current xfsprogs for-next which has a broken mkfs. xfs_info shows this... meta-data=/dev/sda1 isize=512 agcount=4, agsize=644992 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=1 data = bsize=4096 blocks=2579968, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=4096 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=268435456 extents = zoned=0 start=0 reserved=0 ...observe that the log section has sectsz=4096 sunit=0, which means that the roundoff factor is 512, not 4096 as you'd expect. We should fix mkfs not to generate broken filesystems, but anyone can fuzz the ondisk superblock so we should be more cautious. I think the inadequate logic predates commit a6a65fef5ef8d0, but that's clearly going to require a different backport.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS