The vulnerability resides in the ntfs3 file system driver. During the decompression of an LZNT $DATA frame, the function ni_read_frame() relies on the return value of decompress_lznt(). decompress_lznt() may finish early when the compressed stream ends prematurely, returning a size smaller than the frame size. The remaining bytes of the frame are never overwritten, and the subsequent memset() is skipped when the frame is wholly within the file's valid size, leaving the gap filled with whatever was in the just‑vmapped pages. All pages are then marked uptodate and returned to user space, disclosing uninitialised kernel memory. A specially crafted NTFS file that decompresses to only a few bytes can leak the rest of every frame via a standard read system call, revealing kernel pointers and disabling KASLR. The effect is a direct kernel memory disclosure. An attacker who can cause the system to read such a malformed NTFS file can recover addresses that can in turn be used to bypass address space layout randomisation and facilitate privilege‑escalation attacks. The flaw remains a pure information‑leak; it does not provide arbitrary kernel code execution on its own, but the leaked data is a valuable asset for subsequent attacks. The kernel contains no mitigation flag for this bug; the only remedy is to apply the patch that zeroes the tail of decompressed frames immediately after decompression, ensuring that the unused region never contains sensitive data.

All Linux kernel releases that ship the fs/ntfs3 specific version details are not provided in the advisory, any distribution running a kernel older than the commit that introduces the fix is potentially vulnerable. This includes the broadly deployed mainline kernels and many distribution‑specific backports that have not yet incorporated the patch.

The CVSS score is 5.5, indicating a medium severity disclosure. The EPSS score is < 1%, indicating a very low exploitation probability. The vulnerability is not listed in the CISA KEV catalog, but the exposure of kernel memory can be effectively leveraged to defeat KASLR and aid privilege‑escalation attacks. The exploit requires the ability to read a malicious NTFS file, which is commonly possible on a system with a mounted NTFS volume or with an application that pulls in such data. Consequently the risk is moderate to high for environments that must handle NTFS data, especially if users have local authority to write or read arbitrary files on the volume. Given the attack can be performed via a normal read(2) system call on a crafted NTFS image, the success probability‑level mitigations should be applied promptly, and until such updates are available, the exposure remains an actionable threat.