Cloudanix VulnDB

CVE-2026-99108

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A recent Linux kernel bug can accidentally erase parts of files stored on NTFS drives when the system tries to free up unused space.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

ntfs_trim_fs() incorrectly computes discard ranges by aligning only the start upward while deriving length from the original extent, allowing TRIM operations to extend into and zero allocated clusters beyond free extents when device discard granularity exceeds cluster size.

Why it matters to the business

Risk of silent data corruption on NTFS volumes during routine FITRIM, potentially causing loss of file contents and requiring restores from backup; low immediate urgency given recent publication and minimal exploit activity.

How an attack unfolds

An attacker or script with local access to an affected NTFS mount creates or manipulates unaligned free extents, issues FITRIM, and triggers the kernel to discard beyond the intended range into live clusters, resulting in zeroed data.

How to fix it

Apply the upstream kernel fix that aligns both endpoints of the free extent and skips extents lacking a full discard unit; rebuild and deploy updated kernel packages containing the corrected ntfs_trim_fs() logic.

How to confirm the fix worked

Reproduce the original test case using a 4 KiB cluster NTFS on a device with 32 KiB discard granularity and read-zero-after-trim enabled; confirm no allocated clusters are zeroed after FITRIM and remount.

Typical attack path

  1. Obtain local access or ability to mount and operate on an NTFS filesystem
  2. Create filesystem layout producing free extents not aligned to device discard granularity
  3. Invoke FITRIM ioctl or equivalent discard command
  4. Observe or trigger data loss in subsequently allocated clusters

How to detect it

Search kernel logs and audit trails for FITRIM operations on NTFS mounts around the time of unexpected file corruption; examine filesystem metadata and application logs for sudden blocks of zeroed data following discard commands.

What your security team should do

  • Monitor for availability of patched kernels in distribution repositories and schedule updates within standard change windows
  • Restrict untrusted local access to systems hosting NTFS volumes until patched
  • Review backup and recovery procedures for NTFS data to ensure rapid restoration capability

The record

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.

Affected packages

Ecosystem Package Introduced Fixed