Look up another CVE · open CVE-2026-72470 in the interactive tracker
CVE-2026-72470
fs/ntfs3: resize log->one_page_buf when adopting on-disk page size
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem fs/ntfs3. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-72470 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 | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.100-1 | Update the kernel and reboot. Fixed in 6.12.100-1. A running kernel keeps the old code until the machine restarts. |
| 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
log_replay() allocates log->one_page_buf using the page size that was chosen from the host PAGE_SIZE: log->one_page_buf = kmalloc(log->page_size, GFP_NOFS); Later, when a restart area is found, the log page size recorded on disk is adopted: t32 = le32_to_cpu(log->rst_info.r_page->sys_page_size); if (log->page_size != t32) { log->l_size = log->orig_file_size; log->page_size = norm_file_page(t32, &log->l_size, t32 == DefaultLogPageSize); } If the on-disk page size is larger than the size used for the initial allocation, log->page_size grows but one_page_buf is left at its original, smaller size. A subsequent unaligned read_log_page() then reads log->page_size bytes into the undersized scratch buffer: page_buf = page_off ? log->one_page_buf : *buffer; err = ntfs_read_run_nb_ra(ni->mi.sbi, &ni->file.run, page_vbo, page_buf, log->page_size, NULL, &log->read_ahead); overflowing the allocation. This is reachable when mounting a dirty NTFS volume whose log was formatted with a page size larger than the buffer initially allocated on the mounting host (for example a 64K-log volume mounted on a host that allocated a 4K scratch buffer). Grow one_page_buf when the adopted on-disk page size exceeds the size used for the initial allocation. On krealloc() failure the original buffer is left intact and freed by the existing error path.
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/fslog.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.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 6.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- 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 |
|---|---|---|
| 5.15 | 6.6.145 | 2097a2537d9d |
| 5.15 | 6.12.97 | f1422df595d6 |
| 5.15 | 6.18.40 | 4f129fc6f756 |
| 5.15 | 7.1.5 | c99444f6dfca |
| 5.15 | 7.2 | 5a35454179fe |
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:LAttack vector, local
- The flaw is triggered only during local block-device mount via the mount/fsmount syscall path (ntfs_fill_super → ntfs_loadlog_and_replay → log_replay); ntfs3 is not reachable from network-facing kernel services.
- AC:LAttack complexity, low
- An attacker fully controls the crafted NTFS $LogFile on disk (sys_page_size larger than host PAGE_SIZE, valid restart area, and LSNs yielding unaligned read_log_page), so the overflow is reliably reproducible without races or victim-specific memory layout.
- PR:LPrivileges required, low
- Exploitation requires mounting the malicious volume, which needs CAP_SYS_ADMIN; per kernel CNA guidance this is Low because unprivileged users can obtain that capability inside a user namespace and mount a loop-backed NTFS image.
- UI:NUser interaction, none
- No victim interaction is required when the attacker mounts their own crafted NTFS image (loop device or block device they control); log replay runs automatically during mount before any separate user file access.
- S:UScope, unchanged
- Impact is confined to kernel memory corruption and privilege escalation on the mounting host; it does not cross a VM, container, or IOMMU security boundary into another authority.
- C:HConfidentiality impact, high
- The heap overflow writes attacker-controlled $LogFile data up to the adopted log page size (e.g., 64 KiB) beyond a smaller kmalloc buffer, corrupting adjacent kernel objects and enabling arbitrary memory disclosure primitives.
- I:HIntegrity impact, high
- ntfs_read_run_nb_ra writes log->page_size bytes into an undersized one_page_buf, causing an out-of-bounds heap write of attacker-controlled data that can be leveraged for arbitrary kernel modification or code execution.
- A:HAvailability impact, high
- Corrupting kmalloc heap metadata or adjacent objects during log replay typically causes kernel oops/panic or hang, denying service on mount of a malicious NTFS volume even when full exploitation is not attempted.