PT-2026-90332 · Linux · Linux

CVE-2026-89616

·

Published

2026-09-11

·

Updated

2026-09-11

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-89616

Affected Products

Linux