Look up another CVE · open CVE-2026-72471 in the interactive tracker
CVE-2026-72471
fs/ntfs3: prevent potential lcn remains uninitialized
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-72471 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
The target VCN being sought was not found within runs[0], causing run_lookup() to return false. This causes run_lookup_entry() to return false, which in turn results in a len value of 0, and the new parameter passed to attr_data_get_block() is NULL. Collectively, these factors ultimately cause attr_data_get_block_locked() to exit prematurely without initializing lcn, thereby triggering [1]. To prevent [1], the clen check within ni_seek_data_or_hole() has been moved to occur before the lcn check. [1] BUG: KMSAN: uninit-value in ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ni_seek_data_or_hole+0x24f/0x5f0 fs/ntfs3/frecord.c:2862 ntfs_llseek+0x22a/0x4a0 fs/ntfs3/file.c:1530 vfs_llseek fs/read_write.c:391 [inline]
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
- 7.1 high
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:Nsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.33%, higher than 24.4% 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 |
|---|---|---|
| 7.0 | 7.1.5 | 7ae7e98b7143 |
| 7.0 | 7.2 | 57ac2831c8e0 |
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
- On servers exporting an NTFS3-backed volume via ksmbd or nfsd, a remote client can trigger ntfs_llseek(SEEK_DATA/SEEK_HOLE) through FSCTL_QUERY_ALLOCATED_RANGES or NFS SEEK operations, exercising ni_seek_data_or_hole() without local shell access.
- AC:LAttack complexity, low
- The bug is reliably reproducible with attacker-crafted NTFS metadata where the target VCN is absent from runs[0], causing attr_data_get_block_locked() to return success with clen=0 and leave lcn uninitialized; syzkaller demonstrated deterministic triggering.
- PR:LPrivileges required, low
- Exploitation requires only an unprivileged local user with read access to a file on a mounted ntfs3 volume, or an authenticated SMB/NFS client with permission to open/query that file; mounting the filesystem itself is not required for the trigger path.
- UI:NUser interaction, none
- On typical server deployments the NTFS volume is already mounted and exported; the attacker only needs network or local file access to invoke lseek/SEEK_DATA/SEEK_HOLE on crafted metadata, with no additional victim interaction beyond normal file access.
- S:UScope, unchanged
- The flaw is confined to incorrect ntfs3 SEEK_DATA/SEEK_HOLE handling in kernel filesystem code and does not cross VM, container, or IOMMU security boundaries; impact remains within the same kernel security authority.
- C:HConfidentiality impact, high
- ni_seek_data_or_hole() compares uninitialized stack variable lcn against RESIDENT_LCN/EOF_LCN/SPARSE_LCN before validating clen==0, constituting a kernel uninitialized-memory read whose branch outcomes and returned seek offsets can leak kernel stack residue to userspace or remote SMB/NFS clients.
- I:LIntegrity impact, low
- Garbage lcn values can force incorrect SEEK_DATA/SEEK_HOLE results (wrong offsets, premature -ENXIO, or invalid positions), corrupting the integrity of file-offset queries returned to local processes or remote clients even though no arbitrary kernel write primitive is demonstrated.
- A:NAvailability impact, none
- The reported failure mode is a KMSAN uninit-value in ni_seek_data_or_hole(); production kernels without KMSAN take mis-branches that return errors or incorrect offsets rather than oopsing, panicking, or hanging the system.