If you plug an external drive into a Linux box and it feels slower than it should, the problem is almost always the NTFS driver. Most users do not even know they have a choice. The default driver many distros still ship for Windows-format volumes is NTFS-3G, a userspace implementation that runs through FUSE (a Linux subsystem that lets filesystem code run outside the kernel, at the cost of extra context switches). NTFS-3G has been around for almost two decades. It works. It is also dramatically slower than what your kernel can do natively, and it just shipped a security release that closes six memory corruption bugs.
NTFS-3G 2026.9.18 is the version that fixed those bugs. The release notes look like internal API call names because that is what got patched, but the practical effect matters. If you still depend on NTFS-3G, update. If you do not have to depend on it anymore, switch drivers.
The performance gap nobody talks about
If your only experience with external drives on Linux is “it works, but it is slow,” the driver is the reason. NTFS-3G is a userspace driver that runs through FUSE (a Linux subsystem that lets filesystem code run outside the kernel, at the cost of extra context switches). NTFS3 runs in kernel space, which removes the FUSE boundary. Every benchmark I have seen shows NTFS3 is several times faster on sequential writes and uses far less CPU on the same hardware.
For external SSDs in particular, the gap is dramatic. A USB-C enclosure that does not break a sweat under NTFS3 can peg a CPU core under NTFS-3G, which is the kind of thing that turns a file copy into a reason to put the laptop down for ten minutes. The fix is the same one that fixes every “Linux is slow with external drives” complaint I have heard in the last three years. Switch drivers.
What 2026.9.18 actually patches
The release is labeled a security update because it patches memory corruption bugs across multiple internal functions. Six separate issues, which suggests the maintainers did an audit rather than chasing one crash report. Each bug affects a different internal function, which is itself a signal that the codebase has been treated with care over the last release cycle.
The headline items:
- Heap buffer overflows in ntfs_external_attr_find, ntfs_ea_check_wsldev, ntfs_check_restart_area, ntfs_same_sid, and ntfs_acl_owner
- A heap out-of-bounds read and write in ntfs_ie_add_vcn
- A heap data corruption issue in ntfs_mapping_pairs_decompress_i
- A denial-of-service issue in ntfs_inode_attach_all_extents
- Stricter handling of creator-owner and creator-group ACEs during ACL inheritance, which closes off a class of attacks where a malicious permission structure grants broader access than it should
A userspace driver that mounts untrusted volumes just shipped six memory safety patches in one drop. That is the kind of release that goes on a patching schedule, not the kind you ignore.
The bug that quietly breaks filesystems
The most worrying single fix is in ntfsresize, the tool that grows and shrinks NTFS volumes. If you used ntfsresize recently and the first extent of $MFT (the master file table, NTFS’s index of every file on the volume) had to be relocated, the tool could leave a stale copy of $MFTMirr (the redundant backup copy of that index) behind. That is the fallback copy the filesystem uses if $MFT itself ever gets corrupted. A stale fallback means the next time the volume gets read, you can end up with old data appearing as if it were current. Files “vanishing” without the disk being bad is exactly the symptom this kind of bug produces.
If you ran ntfsresize on a production volume, plan to verify the filesystem after the update.
Native NTFS3 is the boring answer
Linux has had NTFS3 in the kernel since the 7.1 series. Every current distro ships it. NTFS3 is the in-kernel driver Paragon contributed upstream years ago, and it has matured across the 7.2 and 7.3 lines. For most users, it is the right choice.
The argument against NTFS3 used to be bugs around extended attributes, sparse files, and a handful of journaling edge cases. Most of those are fixed. If your distro is current and your kernel is 7.2 or later, the in-kernel driver handles everything a typical external drive needs.
Check which driver is mounting your NTFS volumes right now:
mount | grep ntfs
The type column tells you:
fuseblkorntfs-3gmeans the slow userspace driverntfs3means the fast in-kernel driver
If you see fuseblk and your kernel is recent, switch. The fix on systemd-based distros is usually a fstab change or letting the automounter pick ntfs3 automatically. After you confirm everything works, remove the ntfs-3g package. One less userspace component between your files and the disk.
Who actually needs NTFS-3G in 2026
There are real reasons to keep it:
- Older kernels that predate NTFS3’s merge
- Long-term-support distributions pinned to 7.0 or earlier
- NAS distros that ship NTFS-3G as the default for cross-platform compatibility
- Workflows that depend on an NTFS-3G-specific feature the kernel driver does not yet implement
If you are in one of these buckets, 2026.9.18 matters today. Update. Treat the driver the same way you would treat any other parser that handles attacker-controlled input, which is to say: patch on a schedule, not when you feel like it.
If you are on a current distro with a recent kernel, none of this is urgent for you. You are almost certainly already on NTFS3. The release is interesting background reading and a reminder that the older driver exists for legacy reasons, not because anyone shipping a fresh Linux install should be picking it.
Trade-offs
NTFS3 is faster, safer, and lower-overhead, but it is not feature-complete against NTFS-3G. There are corner cases around NTFS reparse points, certain encryption metadata layouts, and a handful of obscure compression flags where the in-kernel driver still has rough edges. If your workflow depends on one of those, NTFS-3G is the right choice for you and the update matters.
For everyone else, the cost of staying on NTFS-3G is real. Slower transfers, more CPU usage, and a larger attack surface against an external drive that probably contains files you do not want to lose.
The decision is not “which driver is better in the abstract.” It is “what kernel are you on, and what does your distro default to.” Run mount | grep ntfs and the answer is right there. Once you have it, the choice between NTFS3 and an updated NTFS-3G comes down to a single question: do you actually need a feature the kernel driver does not implement?
What I would tell past me
Three lessons, addressed to the version of me that spent a Saturday wondering why file copies were slow:
- Check the driver first. Every “why is my external drive slow” session starts with
mount | grep ntfs. If you seefuseblk, switch tontfs3before debugging anything else. - Trust the kernel driver on modern hardware. The 7.1-merge NTFS3 was rough. The 7.2 and 7.3 series is solid. If your distro is current, the kernel driver handles the workflows most people actually use.
- Update NTFS-3G when you keep it. A userspace parser handling untrusted input is a security boundary. Patch it on a schedule.