Cloudanix VulnDB

CVE-2026-98141

None

CVSS

—

EPSS

0.1%

Published

Sep 25, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux file handling for certain drives could make programs think they successfully created shortcuts or special files when those files were never actually recorded, leading to unexpected missing links later.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Other
Component
OS kernel
Class
Other
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The update_reparse_data function in the NTFS driver ignores the return value from set_reparse_index, so index insertion failures trigger cleanup that removes written reparse data yet still return success to callers such as symlink(2) and WSL special-file creation; when oldsize is zero the failure is likewise dropped.

Why it matters to the business

Applications and scripts that create symlinks or WSL reparse points on NTFS volumes receive false success indications, producing missing or inconsistent on-disk metadata that can break workflows, cause later access failures, or leave filesystems in an unexpected state.

How an attack unfolds

An unprivileged local process issues symlink or equivalent WSL reparse-point creation calls against an NTFS mount; the kernel path silently discards the index error, returns zero to userspace, and leaves the filesystem without the expected reparse data, enabling subsequent operations that assume the link exists to fail or behave incorrectly.

How to fix it

Upgrade the Linux kernel to a version containing the propagated error return from set_reparse_index inside update_reparse_data; rebuild and reboot with the corrected driver.

How to confirm the fix worked

Inspect the NTFS driver source for error propagation from set_reparse_index; exercise symlink creation under controlled index-failure conditions and confirm the syscall now returns an error instead of zero.

Typical attack path

  1. Mount an NTFS volume on Linux
  2. Invoke symlink(2) or WSL reparse-point creation
  3. Receive successful return code while index insertion actually failed
  4. Observe absence of reparse data on subsequent access or fsck

How to detect it

Search kernel logs and audit trails for NTFS reparse or index-related error paths around the time of symlink or WSL file-creation syscalls; examine filesystem metadata for reparse points that were reported created but are absent from the index.

What your security team should do

  • Prioritize kernel package updates on all systems mounting NTFS volumes
  • Add regression tests that verify symlink and reparse-point creation return proper errors on index failure
  • Review application code that assumes successful symlink creation without subsequent verification

The record

In the Linux kernel, the following vulnerability has been resolved: ntfs: propagate reparse index insertion failure update_reparse_data() ignores the return value of set_reparse_index(). When index insertion fails, the code removes the just-written reparse data as cleanup but still returns 0, so symlink(2) (and WSL special file creation) reports success while no reparse data exists on disk. When there was no previous reparse data (oldsize == 0), the failure was likewise silently ignored. Propagate the error to the caller.

Affected packages

Ecosystem Package Introduced Fixed