NTFS3 Kernel Bugs Let a Malicious Disk Corrupt Linux Memory

A sixteen-year-old spotted two memory bugs in the Linux kernel’s NTFS driver. That is the code that reads Windows disks. Both rated 7.8 HIGH. Then the kernel maintainers named his fix in the official record. 🧐

His name is Pavitra Jha. He has been using Linux since he was seven and looking for vulnerabilities since he was nine. He works the hard targets: browser engines, Android, Windows, and the Linux kernel, the low-level parts where memory corruption and privilege escalation live. On his site he lists Hall of Fame credits from Google, Oracle, NASA, Philips and MoonPay, and the Indian Book of Records title as the youngest ethical hacker in India. He reached out to me on LinkedIn, said he liked my content, and shared his write-up on these two bugs.

Both bugs live in ntfs3. That is the driver that lets Linux read and write NTFS disks, the filesystem Windows uses. Plug a Windows-formatted USB stick into a Linux machine and this is the code that makes sense of it. Paragon Software wrote it, and it has been in the kernel since version 5.15, back in 2021. When a disk was not shut down cleanly, NTFS keeps a journal so it can recover the last changes the next time it mounts. The kernel replays that journal at mount time. During the replay, it reads a handful of numbers straight off the disk and trusts them.

Nothing checks those numbers against the size of the thing they are meant to fit inside.

That is the bug. Twice.

The two flaws:

• → CVE-2026-64532, a heap out-of-bounds write. An offset field called data_off tells a memmove where to write, and nothing checks it lands inside the entry. Push it to 0xFFFC and the write lands 32 bytes past the end, into whatever the kernel put next to it. It happens twice, in two branches of the same function.
• → CVE-2026-64533, a heap out-of-bounds read and write. A count called lcns_follow sets how many bytes a memmove copies, read off the disk with no upper limit. Feed it 0x1FFFFFFF and the copy balloons to roughly four gigabytes. The same count gets reused as a loop limit later, which hands over a second out-of-bounds read and write for free.

On the second bug, the developer had even left a note in the code, right above the copy: // NOTE: Danger. Check for of boundary. The warning was there. The check was not.

Same severity on both, 7.8 HIGH. Same profile too. The attack is local. Someone has to mount a malicious NTFS image on the machine:

• → a booby-trapped USB stick
• → a disk image handed over and opened
• → an automount daemon that mounts removable media on its own

There is no sign it has been used in the wild. It is kernel memory corruption, triggered by mounting a disk you should not have trusted.

These two are not the first bugs of this kind in ntfs3. Reading the metadata off an NTFS disk and trusting it is a spot where the driver has gone wrong before. A malformed image has already caused an infinite loop in one function (CVE-2025-71265) and an integer overflow in another (CVE-2026-46062), and an automated fuzzer runs against ntfs3 without pause, with a backlog of open findings still waiting. Trusting numbers that came straight from the disk is the recurring mistake.

The official CVE record for 64532, on kernel.org, describes the fix and then adds a line that is easy to miss. The fix is “similar in shape to Pavitra Jha’s 2026-05-02 patch,” with the message ID of the patch he mailed to the kernel developers. He did not just report a crash. On the 2nd of May he sent in his own fix. The maintainers went with an inline bounds check instead of the helper he proposed, but they landed a patch in the same shape as his, and they put his name in the record. That naming is on the first bug. The second, 64533, is his find as well, laid out in his write-up, though its official entry does not carry his name. The fixes are merged upstream and backported to six stable branches.

This is the actual code from his write-up, the vulnerable path and the fix, not a simplified version.

The write, with nothing checking data_off:

1
2

e = Add2Ptr(attr, le16_to_cpu(lrh->attr_off));
memmove(Add2Ptr(e, le16_to_cpu(e->view.data_off)), data, dlen);

The fix, with the bounds check added first:

1
2
3
4
5
6
7
8

e = Add2Ptr(attr, le16_to_cpu(lrh->attr_off));
{
    u32 off  = le16_to_cpu(e->view.data_off);
    u32 size = le16_to_cpu(e->size);
    if (off > size || dlen > size - off)
        goto dirty_vol;
}
memmove(Add2Ptr(e, le16_to_cpu(e->view.data_off)), data, dlen);

Three lines. Check the offset sits inside the entry, check the write does not run past the end, then copy. That is all that was missing. The code that reads these same entries already did the check. The recovery path never did.

This was not his first. Earlier this year he was credited for CVE-2026-43495, an out-of-bounds read in the MediaTek t7xx modem driver, backported to five stable branches. Same shape of work: input from a device or a disk that the kernel trusted more than it should have.

What to do about it:

• → Update your kernel. The fixes for both are merged and pushed to the stable branches.
• → Be wary of mounting an NTFS image or a USB stick from a source you do not trust. Mounting alone can reach kernel code, before you open a single file on it.

The thing I keep coming back to is the age. Reading kernel recovery code closely enough to catch a single field that was never bounds-checked, then writing a patch the maintainers took the shape of, is hard at any age. Pavitra is sixteen, doing it in the open, and he took the time to message me about it. That is the kind of person this field needs more of.

Finding and exploiting vulnerabilities the way attackers do, working with actual CVEs and proof-of-concept code, and the full path from reconnaissance to exploitation are exactly what I teach step by step in my ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

CVE-2026-64532 | CVE-2026-64533 | Linux kernel source, fs/ntfs3/fslog.c