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
Affected Products
Linux