Shore Up
a hand inserting a suspicious USB stick into a locked machine while a padlock hangs unused on the side
LinuxSecurity

NTFS-3G Gets a Pile of Overflows — But Ask Where You Actually Mount NTFS

Ketan Aagja3 min read

Debian shipped DSA-6389-1 for ntfs-3g on 15 July, and Ubuntu followed with USN-8554-1 the next day. Between them they close a batch of nine CVEs: seven heap buffer overflows (CVE-2026-42616, 42617, 42618, 46569, 46570, 46572 and 56135) and two out-of-bounds reads (CVE-2026-46571 and 56136). The overflows can lead to arbitrary code execution; the reads can leak memory contents.

That is a long list, and a long list of "arbitrary code execution" entries is exactly the kind of thing that makes people reach for apt before finishing their coffee. Before you do, it's worth being clear about what these bugs actually require, because for a lot of the machines I care about the honest answer is: this matters less than the CVE count suggests.

The word doing all the work is "local"

Read Ubuntu's own phrasing and every single one of these is a local attacker "processing certain NTFS images." Nothing here is remote. Nothing here is triggered by mail, by SMTP, by a message body, by a malicious attachment sitting in a spool. The attack surface is the code that parses an NTFS filesystem, and it only lights up when that code is pointed at a hostile image.

So the question that decides your exposure is simple: on this box, who gets to hand ntfs-3g an untrusted NTFS filesystem to mount?

On a headless Postfix/Dovecot server, iRedMail appliance, or a Zimbra host, the usual answer is "nobody." You don't plug USB sticks into a mail relay. Your mail spool lives on ext4, XFS, or whatever your storage layer presents — not NTFS. ntfs-3g may well be installed as a dependency you've never thought about, but if it never touches attacker-controlled data, these bugs never fire. That doesn't mean skip the update — it means you can schedule it with the rest of your patch window instead of declaring an incident.

Where it actually bites

The machines that should move quickly are the ones that mount NTFS from sources they don't control:

  • Desktops and laptops with automount. Plug in a USB drive or SD card and udisks will happily mount NTFS for you. A crafted image on removable media is the textbook local vector here.
  • Forensics, recovery, and imaging boxes that mount disk images or evidence drives as a matter of routine — those are handling exactly the "certain NTFS images" the advisory warns about.
  • Backup or migration hosts that loop-mount NTFS images pulled off Windows systems.

If that's you, patch now, not this weekend.

Doing the update

Both distributions treat this as a routine package refresh. Ubuntu's notice says plainly that a standard system update applies the fix, and lists fixed versions for 22.04, 24.04 and 26.04. Debian's source advisory body wasn't retrievable at the time of writing — only the tracker link came through — so if you're on Debian, check the fixed version against the security tracker referenced in DSA-6389-1 rather than trusting a version number from memory.

One practical note the advisories don't spell out: an already-mounted, trusted NTFS filesystem doesn't re-parse itself after you upgrade the package. The safe move is to unmount and remount anything mounted through ntfs-3g once the new version is in place, so the patched code is what's actually running.

Full details are in Ubuntu's USN-8554-1.