News › security
By The Linux Camp News, October 28, 2026
The October 28 pull request addresses mount-time memory corruption and data leaks, plus defects affecting healthy NTFS volumes. Submission does not establish release or distribution availability.
On October 28, 2026, Konstantin Komarov submitted NTFS3 changes targeting Linux 7.4-rc1, with hardening against corrupted or maliciously crafted volumes as the main focus. NTFS3 is an in-kernel NTFS read/write driver. The concrete development is a pull request, not a confirmed merge or released kernel containing the fixes. 1 2
One failure occurs while mounting, during replay of $LogFile, the volume's log. Komarov reports that unchecked sizes read from disk could make NTFS3 write beyond an MFT record buffer. The important boundary is between a size claimed by filesystem metadata and the memory available to hold that record: accepting the former without sufficient checks can turn processing a damaged volume into a kernel-memory write outside the intended buffer. 2
Extended attributes, the name-and-value metadata associated with files, present a separate disclosure path. A malformed $EA entry could expose up to 64K of kernel heap through getxattr(), according to the maintainer. One listed fix checks that an attribute entry is large enough to contain its declared name and value. That check addresses the mismatch between the entry's boundary and the contents the driver is asked to interpret. 2 1
The operational scope extends beyond suspicious media. The request also addresses damaged compressed-file reads returning uninitialized page-cache contents. On healthy volumes, Komarov lists a small-file fallocate(INSERT_RANGE) heap overflow, a use-after-free when opening a WOF-compressed file for writing during a concurrent read, a readdir deadlock, and stale disk data appearing in newly allocated compressed-file clusters. The practical inference is that workload matters as well as volume integrity: an undamaged filesystem does not rule out relevance. 2
A separate configuration change deserves review for file-creation workflows. The proposed ugm mount option defaults to on; selecting ugm=0 suppresses WSL uid/gid/mode extended attributes on newly created files. Komarov says Windows does not use those attributes. Before choosing that setting, check whether the workflow depends on storing that metadata. The described scope is new files, not a conversion of existing files or a security mitigation for the parsing defects. 2
Komarov attributes most fixes to fuzzing and KASAN reports; Phoronix expands KASAN as Kernel Address Sanitizer. That establishes a testing origin for much of the work, not observed exploitation against deployed systems. The supplied reporting does not establish an exploitation history, and the maintainer's defect descriptions should not be read as CVE severity scores. 2 1
As of the October 28, 2026 source retrieval, the packet establishes submission but not mainline acceptance, stable backports or distribution package availability. It also does not provide affected-version ranges or establish whether read-only mounting avoids individual defects. Deployment decisions therefore need follow-up evidence about inclusion of the fixes; this pull request alone cannot establish the patch status of a particular running distribution kernel. 2