Look up another CVE · open CVE-2026-72477 in the interactive tracker
CVE-2026-72477
fs/ntfs3: call _ntfs_bad_inode() when failing to rename
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/ntfs3. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72477 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
It is safe to call _ntfs_bad_inode on live inodes since: commit 519b078998ce ("fs/ntfs3: Exclude call make_bad_inode for live nodes.") The WARN_ON was added when it wasn't safe by: commit d99208b91933 ("fs/ntfs3: cancle set bad inode after removing name fails") Replace the WARN_ON with a call to _ntfs_bad_inode() to prevent further operations on the inconsistent inode.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
fs/ntfs3/frecord.c
- What this is
- NTFS3 FILESYSTEMMAINTAINERS section matched on fs/ntfs3/ · ntfs3@lists.linux.dev · Supported
- Kernel module
- ntfs3
Check it on the machine
grep -w CONFIG_NTFS3_FS /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w ntfs3Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. It does build it in 1 release, so the answer depends on which release the machine runs.
- bookwormn
- trixiem
- forky, sidn
- n
- not enabled on any flavour - this release does not build the code
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_NTFS3_FS
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-15 (2 months ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.65%, higher than 50.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- fs/ntfs3
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.17 | 6.18.57 | 580896e33003 |
| 6.17 | 7.1.5 | ff825bf0521f |
| 6.17 | 7.2 | e8ed78f40eec |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- ntfs3 registers export_operations and rename on an NFS- or SMB-exported NTFS volume reaches ni_rename() through nfsd/ksmbd vfs_rename without any local syscall; hybrid NAS and Windows/Linux file-server deployments are a reasonable high-impact reach path for this VFS rename flaw.
- AC:LAttack complexity, low
- An attacker controls the on-disk NTFS layout and rename arguments so ni_add_name succeeds and both ni_remove_name steps fail deterministically; syzkaller reproduces this with a crafted loop image and no races or victim-specific timing outside attacker influence.
- PR:NPrivileges required, none
- Exploitation needs only permission to rename on an exported NTFS share (including guest/anonymous NFS or SMB write access) or to supply removable media later mounted by the host; no init-namespace root, CAP_SYS_ADMIN, or other elevated host credentials are required.
- UI:NUser interaction, none
- Once an administrator has mounted and exported the NTFS volume (or automounted dual-boot/shared storage), the attacker triggers the flawed rename directly; no further victim clicks, file opens, or cooperative actions are needed beyond that standing configuration.
- S:UScope, unchanged
- Impact is kernel heap/metadata corruption and denial of service within the same kernel security authority; this is standard local or network filesystem exploitation, not a VM escape, IOMMU bypass, or cross-scope sandbox breakout.
- C:HConfidentiality impact, high
- Leaving the inode operable after a failed rename rollback preserves inconsistent MFT/directory index state; subsequent lookups and index walks parse attacker-influenced corrupt metadata, matching ntfs3 guidance to score metadata corruption that can yield kernel memory disclosure as High.
- I:HIntegrity impact, high
- Without ni_bad set, further writes, unlinks, and renames continue against mismatched $FILE_NAME and $I30 state, propagating attacker-steerable directory/MFT corruption and heap metadata damage that can be leveraged for arbitrary kernel writes or control-flow hijack.
- A:HAvailability impact, high
- The vulnerable path emits WARN_ON in ni_rename (kernel panic on panic_on_warn) and syzbot also hit a kernel paging fault in folio_wait_bit_common after follow-on operations on the inconsistent inode; any kernel oops, hang, or panic from continued use scores Availability High.