CVE-2026-89616
High · 7.5CVSS
7.5
EPSS
0.4%
Published
Sep 11, 2026
CISA due date
—
Cloudanix analysis
A flaw in how Linux handles certain compressed files on NTFS drives can accidentally reveal secret kernel memory to regular programs, making it easier for attackers to break into the system.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability allows reading uninitialized kernel memory through partial LZNT decompression in ntfs3, where the tail of the frame is not zeroed after decompress_lznt returns a smaller unc_size, leaking data from recently freed pages including kernel pointers.
Why it matters to the business
Attackers can obtain sensitive kernel memory contents remotely by reading crafted NTFS files, potentially bypassing address space layout randomization and aiding further attacks on the system; low EPSS and no known exploitation reduce immediate risk but the 43-day-old flaw still warrants patching on Linux systems handling NTFS.
How an attack unfolds
An attacker crafts a compressed NTFS data stream that decompresses to fewer bytes than the frame size. When the kernel reads the file via ni_read_frame, the partial data with uninitialized memory in the gap is returned to userspace via read(2), allowing extraction of kernel pointers to defeat KASLR.
How to fix it
Apply the kernel patch that zeros the [unc_size, frame_size) region immediately after a successful LZNT decompress in ni_read_frame().
How to confirm the fix worked
Verify the patch is applied by inspecting fs/ntfs3 for the added memset after decompress_lznt success, or test with crafted partial-compress files to confirm the gap reads as zero instead of prior page contents.
Typical attack path
- Craft malicious NTFS file with partial LZNT stream
- Place file on system or share accessible to target
- Trigger read via userspace application or mount
- Extract leaked kernel memory from read buffer
- Use pointers to defeat KASLR for further exploitation
How to detect it
Monitor for processes performing reads on NTFS compressed streams that return unexpected data lengths; correlate with kernel logs for ntfs3 decompression errors, though primary detection relies on post-patch verification as no runtime artifacts are produced by the leak itself.
What your security team should do
- Update Linux kernel to include the ntfs3 LZNT zeroing fix
- Restrict untrusted NTFS filesystem access where feasible
- Audit systems mounting external NTFS volumes for exposure
The record
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame() ni_read_frame() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompress_lznt()'s return value: unc_size = decompress_lznt(frame_ondisk, ondisk_size, frame_mem, frame_size); if ((ssize_t)unc_size < 0) err = unc_size; else if (!unc_size || unc_size > frame_size) err = -EINVAL; decompress_lznt() stops as soon as the compressed stream is exhausted (e.g. a zero chunk header) and returns the number of bytes it actually wrote, which may be far less than frame_size. The bytes between unc_size and frame_size are never written. The only memset() that follows zeroes the region beyond i_valid; when the frame lies entirely within the file's valid size that memset() does not run, so the gap retains whatever was in the just-vmapped pages. All pages are then marked uptodate and returned to userspace, disclosing uninitialized (recently-freed) kernel page memory. A crafted compressed file whose stream decompresses to only a few bytes leaks the remainder of every frame on a plain read(2), which is enough to recover kernel pointers and defeat KASLR. Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress so the remainder reads back as zero.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|