A newly disclosed kernel fix addresses a quiet but dangerous flaw in Linux’s built-in NTFS driver that could expose sensitive memory when the system mounts an untrusted USB stick or disk image. The patch, assigned CVE-2025-68365, swaps a single memory allocation call for its zeroing counterpart, preventing the driver from reading uninitialized kernel heap data. While no active exploits have been reported, administrators are urged to update because the attack surface—any host that processes NTFS images from third parties—is broader than it appears.

Inside the Patch

The discovery came from the Kernel Memory Sanitizer (KMSAN), a tool that flags reads of uninitialized memory. In the ntfs3 driver, which provides native NTFS read/write support, KMSAN caught multiple functions—including ntfs_read_hdr and bcmp—reading heap data that had never been written to. The root cause was traced to an internal allocation helper, __getname, which in turn called kmem_cache_alloc. This function returns freshly allocated memory without clearing it, so its contents are whatever was leftover from previous uses. When ntfs3 code later parsed those bytes as NTFS metadata, any garbage values could lead to incorrect decisions, kernel logic errors, or, in some cases, the exposure of adjacent kernel memory.

The fix is strikingly simple: replace the non-zeroing kmem_cache_alloc with kmem_cache_zalloc, a variant that automatically fills the allocated memory with zeros. Zeros represent “no data” and are safe defaults in filesystem code; they prevent uninitialized values from influencing control flow. The upstream commit accepted into the stable kernel tree makes this change in precisely the locations flagged by the sanitizer. Because the alteration is minimal and confined to a well-understood initialization path, the risk of regression is low. Distributions have already begun backporting the patch to their kernels; Debian, for instance, lists affected package ranges and corresponding updates.

Are You at Risk?

Any Linux system that mounts or inspects NTFS filesystems is potentially affected. That includes far more than just dual-boot desktops with Windows partitions. Consider these scenarios:

  • Virtualization hosts: When a VM spins up with an attached NTFS virtual disk, the host kernel may interact with the filesystem during image import or snapshot operations.
  • CI/CD pipelines and build servers: Automated processes that download, extract, or inspect NTFS images from untrusted sources are directly exposed.
  • Backup and forensic appliances: These often mount disk images from compromised or foreign systems, making them ideal targets.
  • Everyday Linux users: Simply plugging in a USB drive formatted with NTFS—perhaps borrowed or found—could trigger the vulnerability.

The attack does not require remote network access. An attacker must get the kernel to parse a specially crafted NTFS image, which can be delivered via a physical device, a download link, or an email attachment. Once mounted, the malformed data could cause a kernel oops (denying service), leak fragments of kernel memory, or corrupt filesystem operations. While direct remote code execution is not an obvious outcome, kernel information leaks have historically been chained with other bugs to gain deeper control. Therefore, treat this as a privilege-sensitive correctness bug rather than a theoretical worry.

A Timeline of NTFS in the Kernel

Linux’s relationship with NTFS has been checkered. For years, the out-of-tree NTFS-3G (FUSE-based) driver was the go-to for write support, while the kernel’s own ntfs driver was read-only and largely unmaintained. In 2019, Paragon Software open-sourced its ntfs3 driver, and it was merged into the mainline kernel in 2021. Suddenly, Linux could read and write NTFS natively, with performance close to that on Windows. But with that deep integration came a larger attack surface: ntfs3 now runs in privileged kernel context, parsing complex on-disk structures directly.

Automated testing tools like syzbot and KMSAN have been instrumental in uncovering flaws in this still-young code. The bug behind CVE-2025-68365 was spotted by KMSAN—a dynamic instrumentation framework that tracks every byte of memory, flagging any use before init. The report was filed, the fix was developed, and the CVE was published on December 24, 2025. The Microsoft Security Response Center’s advisory page for this CVE currently displays only a placeholder disclaimer, which is not unusual early in the lifecycle. Independent trackers such as OpenCVE and the Debian Security Tracker, however, do list the issue and point to the kernel commits that resolve it.

Your Action Plan

The best defense is a patched kernel. But until your distribution ships the update, you can reduce your exposure. Here’s what to do, from immediate checks to long-term hardening.

Check if ntfs3 is active

On any suspect machine, run these commands:

sudo modinfo ntfs3          # Shows module details if ntfs3 is a loadable module
lsmod | grep ntfs3         # Lists the module if currently loaded
zgrep CONFIG_NTFS3_FS /proc/config.gz   # Displays whether ntfs3 is built as module (=m) or built-in (=y)

If ntfs3 is built into the kernel (CONFIG_NTFS3_FS=y), module blacklisting will not work; you must replace the kernel image. If it’s a module, proceed to the next step.

Short-term mitigation for modular kernels

As a stopgap, prevent the ntfs3 module from loading:

echo "blacklist ntfs3" | sudo tee /etc/modprobe.d/ntfs3-blacklist.conf
sudo update-initramfs -u   # (or dracut --force, depending on your distro)
sudo reboot

After reboot, confirm the module is not loaded with lsmod | grep ntfs3. This eliminates the risk of the vulnerable code path being executed, but it also removes the ability to mount NTFS volumes. Ensure that your workflows can tolerate a temporary loss of NTFS support.

Patch and verify

Once your vendor releases a fixed kernel package, update immediately. After rebooting, verify the new kernel version:

uname -r

Check the distribution’s changelog for mention of CVE-2025-68365 or the upstream commit ID. Monitor the system logs (dmesg, journalctl) for a few days to catch any residual ntfs3-related errors.

Isolate high-risk workflows

If you cannot patch or blacklist in certain environments—for instance, a CI runner that must process NTFS images—isolate those tasks in disposable virtual machines or containers that can be regularly rebuilt with updated kernels. Never run such workflows on the same machine that handles sensitive data or critical services.

Looking Ahead

The ntfs3 driver will likely see more of these correctness patches as sanitizer coverage expands. For system administrators, it’s a reminder to treat kernel filesystem drivers as prime attack surfaces. Automate the inventory of kernel modules across your fleet, and prioritize patches for anything that parses complex input from external sources. The simple zeroing fix behind CVE-2025-68365 demonstrates that even a single omitted initialization can become a security liability—but it also shows that modern tooling catches these problems before they are widely exploited. Stay on the update cadence, and keep an eye on your distribution’s security tracker for the final package numbers.