CVE-2026-89616: fs/ntfs3: fix info-leak on partial LZNT decompress in ni_read_frame()
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: fix info-leak on partial LZNT decompress in nireadframe()
nireadframe() decompresses an LZNT $DATA frame into the vmapped target pages and then trusts decompresslznt()'s return value:
uncsize = decompresslznt(frameondisk, ondisksize, framemem, framesize); if ((ssizet)uncsize < 0) err = uncsize; else if (!uncsize || uncsize > framesize) err = -EINVAL;
decompresslznt() 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 framesize. The bytes between uncsize and framesize are never written. The only memset() that follows zeroes the region beyond ivalid; 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 [uncsize, framesize) tail immediately after a successful LZNT decompress so the remainder reads back as zero.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Apply the fs/ntfs3 fix in ni_read_frame() so that after a successful LZNT decompression, the bytes in the tail range [unc_size, frame_size) are zeroed immediately; this prevents an info-leak of uninitialized/recently-freed kernel memory on plain read(2) when decompress_lznt() writes less than frame_size.
Linux kernel (fs/ntfs3) LZNT partial decompression zeroing = Zero the [unc_size, frame_size) tail immediately after a successful LZNT decompress
Event History
Frequently Asked Questions
Who is exposed to this issue?
Systems using the Linux kernel ntfs3 filesystem driver are exposed when they read a crafted NTFS file containing compressed LZNT $DATA frames. The leak occurs through a normal read(2) of the affected file.
What does an attacker need to exploit it?
An attacker needs to provide a crafted compressed NTFS file whose compressed stream decompresses to only a small amount of data relative to the frame size. Reading that file can return unwritten portions of vmapped pages to userspace.
What information can be disclosed?
The unwritten portion of each affected frame can contain uninitialized, recently freed kernel page memory. The disclosed data may include kernel pointers.
What can be done before the fix is deployed?
Avoid reading untrusted NTFS files that use compressed LZNT data through the ntfs3 driver. In particular, do not mount or process attacker-supplied NTFS content where it may be read by local applications.