Live › vulnerability › CVE-2026-99108
Go to dashboardThe Linux kernel's NTFS driver computes the discard length for FITRIM incorrectly when a free extent does not start on a discard-aligned boundary. The discard can extend into allocated clusters, which can destroy file data on devices that zero data after trim.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 11:32 UTC. All times on this page are UTC.
No product ranges from the sources yet.
Unknown from the sources.
Unknown from the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
ntfs: fix FITRIM range alignment
ntfs_trim_fs() aligns the start of a free extent up to the device discard granularity, but derives the discard length by aligning the original extent length down. When the free extent start is not discard-aligned, adding that length to the aligned start can extend the discard past the free extent and into allocated clusters.
For example, with 4 KiB clusters and 32 KiB discard granularity, the free extent [4 KiB, 36 KiB) becomes the discard range [32 KiB, 64 KiB), so 28 KiB beyond the free extent may be discarded.
Align the absolute end of the free extent down and derive the length from the two aligned endpoints. Skip extents that contain no full discard unit.
Reproduced with a 4 KiB-cluster NTFS filesystem on scsi_debug configured for 32 KiB discard granularity and read-zero-after-trim. Before this change, FITRIM zeroed seven allocated 4 KiB clusters following an unaligned 32 KiB hole. With this change, the same data remains intact across FITRIM and remount.
This page as .md · .json · in your agent: get_signal("CVE-2026-99108")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.