VulnerabilityPublished 28 Oct 2026

CVE-2026-99108: Linux kernel · ntfs: fix FITRIM range alignment

Source GCVE Database

Authoritative record:CVE-2026-99108

Not known to be exploited : upgrade to 5e87da8ba8d3d647d89c754912e45c1f1a3bfc2e or 03c6ecc4b4b13a3901f207152451fdd2d82e40c4 soon.

Data as of 28 Oct 2026, 14:15 UTC

Severity

High

Rated High by Threat Radar's AI analysis · CVSS not yet scored by NVD

Patch: Available – fixed in 5e87da8ba8d3d647d89c754912e45c1f1a3bfc2e, 03c6ecc4b4b13a3901f207152451fdd2d82e40c4

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 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.

ghsa-8qcr-mmv6-jjc8

What to do

Upgrade Linux kernel to 5e87da8ba8d3d647d89c754912e45c1f1a3bfc2e or 03c6ecc4b4b13a3901f207152451fdd2d82e40c4.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 11ccc9107dc460de28af90fac1f42404d9802735, < 5e87da8ba8d3d647d89c754912e45c1f1a3bfc2e	Fixed in 5e87da8ba8d3d647d89c754912e45c1f1a3bfc2e
LinuxLinux	Affected ≥ 11ccc9107dc460de28af90fac1f42404d9802735, < 03c6ecc4b4b13a3901f207152451fdd2d82e40c4	Fixed in 03c6ecc4b4b13a3901f207152451fdd2d82e40c4
LinuxLinux	Affected =7.1	Fixed in–

AI-suggested

A fix for this vulnerability has been implemented in the Linux kernel. Users should update to a kernel version that includes this fix to prevent discard operations from affecting allocated data. Since the input does not specify exact fixed versions or patches, users should consult the Linux kernel release notes or vendor advisories for the fixed version details.

Description

A vulnerability in the Linux kernel's NTFS filesystem driver caused improper alignment of discard (FITRIM) ranges, potentially leading to discard operations extending beyond free extents into allocated clusters. This could result in data loss or corruption when the discard granularity does not align with cluster boundaries. The issue has been fixed by correctly aligning both the start and end of the discard range to the device's discard granularity, preventing discard operations from affecting allocated data.

Impact

The vulnerability could cause discard (FITRIM) operations to zero out or discard allocated clusters beyond the intended free extent, leading to potential data loss or corruption on NTFS filesystems using the Linux kernel. This affects systems where the discard granularity is larger than the cluster size and the free extent is not discard-aligned.

Summary

The Linux kernel NTFS driver function ntfs_trim_fs() previously aligned the start of free extents up to the device discard granularity but aligned the discard length down from the original extent length. This mismatch caused discard operations to extend beyond the free extent into allocated clusters when the free extent start was not discard-aligned. For example, with 4 KiB clusters and 32 KiB discard granularity, a free extent from 4 KiB to 36 KiB was incorrectly discarded from 32 KiB to 64 KiB, affecting 28 KiB of allocated data. The fix aligns the absolute end of the free extent down and calculates the discard length from these aligned endpoints, skipping extents without a full discard unit. This prevents discard operations from corrupting allocated clusters.

References

Community reviews

Loading reviews…