A forged NTFS3 image gives any local user root the moment a USB drive is mounted

Two months. One line of code. euid=0. The Linux kernel’s NTFS3 driver restores setuid bits straight from untrusted on-disk data, meaning a crafted NTFS image on a USB stick produces a setuid-root binary the instant the volume is mounted. Reported privately by its discoverer two months ago, the bug remains unpatched in mainline as of August 22, 2026.

The flaw was made public by Vova Tokarev on the driver’s mailing list after two months without a response. It is a local privilege escalation — you need physical access or a remotely triggered mount — but its trigger is as mundane as a desktop automount.

The mechanism: the mode comes from the disk, not the user

NTFS stores Linux-specific extended attributes (EAs): $LXUID, $LXGID, and $LXMOD. They map Unix ownership and permissions onto files on an NTFS volume. The problem is that the NTFS3 driver trusts those values without filtering them.

In fs/ntfs3/xattr.c, at line 1022, the driver loads the inode mode directly from the attribute read off the disk:

inode->i_mode = le32_to_cpu(value[2]);

That line copies S_ISUID and S_ISGID out of untrusted data. A forged NTFS image can therefore place $LXUID=0, $LXGID=0, and $LXMOD=0104755 straight into the MFT. On mount, the file shows up as owned by root and carrying the setuid bit. No setxattr() call is involved — the extended attributes are already on disk, and the -EPERM check never applies.

Why the automounter makes it worse

The last link is the most ordinary one. Desktop automounters such as udisks mount NTFS volumes with suid enabled by default. Plugging a forged USB stick into a workstation therefore lifts any local user to euid=0, with no explicit elevation ever requested.

Tokarev’s proposed fix is one line: mask the two bits instead of copying them blindly.

inode->i_mode = le32_to_cpu(value[2]) & ~(S_ISUID | S_ISGID);

It is a trivial bitwise mask — which makes the “unpatched” status all the more striking.

A one-line fix, two months of waiting

The discoverer says the issue was reported privately roughly two months before publication, with no resolution. Disclosure therefore went through the NTFS3 driver’s mailing list, complete with a full proof of concept and a working demo.

Phoronix, reporting the story on August 22, 2026, notes the mainline NTFS3 driver had still not received a fix at publication time. The bug does not affect the other NTFS driver still maturing in the kernel tree, nor ntfs-3g, the FUSE userspace driver many distributions use by default.

Workarounds until the patch lands

Until the line is fixed in mainline and backported to stable branches, three measures shrink the exposure:

• Disable automounting of removable media on workstations, or restrict it to an unprivileged session;
• Mount explicitly with nosuid any NTFS volume whose provenance you do not control;
• Switch to ntfs-3g (FUSE) if write access is required, or to the historical read-only ntfs driver.

# Check which driver took over a mounted NTFS volume
mount | grep -i ntfs

# Mount explicitly without suid
mount -t ntfs3 -o nosuid /dev/sdX1 /mnt/ntfs

The check is immediate: if mount prints ntfs3, the volume is handled by the vulnerable driver.

A young driver, already everywhere

NTFS3 is not a marginal driver. Developed by Paragon Software, it was merged into mainline in 2021, with the 5.15 kernel, to offer native read-write access to Windows volumes faster than ntfs-3g, the userspace FUSE alternative. It has since become the default driver on many distributions for automounting NTFS-formatted USB sticks and external drives.

To map Unix ownership and permissions onto a filesystem that has no such notion, NTFS3 relies on Linux-specific extended attributes stored in the MFT: $LXUID, $LXGID, and $LXMOD. It is this interoperability mechanism, built for compatibility, that gets abused: the driver restores those attributes without checking that the privilege bits they carry are legitimate.

Who is affected, who is not

Exposure is uneven. Workstations with a desktop environment are hit hardest: udisks automounts NTFS volumes there with suid, and any user on the machine can plug in a drive. Servers without automounting or physical access are barely exposed.

Not affected by this specific vector: systems that mount explicitly with nosuid, those using ntfs-3g (FUSE, hence userspace, with no direct access to kernel setuid bits), and those using the historical read-only ntfs driver.

Virtualized environments also deserve attention: a virtual machine with USB passthrough replicates the risk inside the guest, and a privileged container mounting an untrusted NTFS volume can transmit the escalation toward the host. The check is one command: if mount prints ntfs3 for a volume whose provenance you don’t control, the risk is present until the patch ships.

The setuid lesson

The setuid bit is one of the oldest and most delicate mechanisms in Unix: it lets a binary run with its owner’s privileges, historically root. For decades, the hygiene rule has been that an administrator sets this bit only on audited binaries, never on a file whose provenance is not controlled. A driver that restores that bit from an untrusted removable medium breaks that rule without anyone having to configure anything.

It is a regression made all the more striking because the fix is trivial — a bitwise mask — and the problem had been known for two months at the time of disclosure. The delay is not technical: it sits in the governance of a driver whose security fixes must still be validated and then backported into every stable branch.

The deeper question is why such a trivial bug survived. NTFS3 carries a large amount of Paragon code merged in one batch, and its security-sensitive paths — like restoring Unix metadata from on-disk attributes — received less scrutiny than the newer, actively refactored NTFS driver. For a system administrator, the practical takeaway is unchanged: removable media is an input you do not control, and mounting it with full privilege semantics is a choice. Until mainline lands the mask, nosuid is the cheap insurance. On a workstation, the one-liner mount -t ntfs3 -o nosuid,uid=1000 /dev/sdX1 /mnt both strips setuid and maps the files to the current user — the sane default for media you do not own.

Verdict

If you manage Linux workstations with unprivileged users who plug in USB drives, apply the workarounds now: disable automounting or force nosuid on NTFS volumes. The risk is real — the exploit is deterministic, with no exotic configuration required — and the patch is not yet shipped.

If you manage servers, exposure is low: a server does not automount removable media, and nobody but an administrator plugs drives into it. Keep the focus on workstations and shared terminals.

The root issue goes beyond NTFS3: a filesystem driver that restores privilege metadata from an untrusted medium recreates the setuid bug the Unix world thought it had learned to contain. A bitwise mask should have closed the file in June — it is still waiting.

References

• Specially Crafted NTFS File-System Image Allows Root Access On Linux With NTFS3 Driver — Phoronix, August 22, 2026
• Vova Tokarev’s post to the NTFS3 mailing list, accessed August 23, 2026