CVE-2025-71067: ntfs: set dummy blocksize to read boot_block when mounting
In the Linux kernel, the following vulnerability has been resolved:
ntfs: set dummy blocksize to read boot_block when mounting
When mounting, sb->s_blocksize is used to read the boot_block without
being defined or validated. Set a dummy blocksize before attempting to
read the boot_block.
The issue can be triggered with the following syz reproducer:
mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0)
r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0)
ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000)
mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00',
&(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0)
syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)
Here, the ioctl sets the bdev block size to 16384. During mount,
get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),
but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves
sb->s_blocksize at zero.
Later, ntfs_init_from_boot() attempts to read the boot_block while
sb->s_blocksize is still zero, which triggers the bug.
[almaz.alexandrovich@paragon-software.com: changed comment style, added
return value handling]
Security readout for executives and security teams
Plain-English summary
CVE-2025-71067 is a Linux kernel NTFS3 filesystem mount bug. A specially prepared mount scenario can make the kernel use an invalid block size while reading NTFS boot data, triggering a kernel fault. The public record shows it is fixed in Linux stable commits. There is no cited evidence of active exploitation.
Executive priority
Treat as a routine but real kernel reliability risk. Prioritize patching systems that mount NTFS media or allow privileged container/device workflows. There is no public evidence here of active exploitation, and impact details are incomplete, so urgency is below remotely exploitable kernel issues.
Technical view
In Linux kernel ntfs3 mount handling, sb->s_blocksize could remain zero when the underlying block device reports a block size larger than PAGE_SIZE. ntfs_init_from_boot() then reads the boot block using that unset value, triggering the bug. The fix sets a dummy block size before reading boot_block and handles return values.
Likely exposure
Exposure is mainly Linux systems with the ntfs3 driver available where untrusted users or workflows can initiate NTFS mounts or attach unusual block devices. Typical servers without NTFS mounting or with tightly controlled mount privileges have lower exposure. Distribution backports may change version-based conclusions.
Exploitation context
The public description attributes discovery to a syzkaller-style reproducer. Triggering appears to require local mount-related capability or a privileged context able to influence a block device and mount ntfs3. No KEV listing or cited source indicates exploitation in the wild.
Researcher notes
The record provides no CVSS, CWE, or detailed impact classification. The affected version data is broad and branch-oriented, so distro-specific assessment requires vendor package mapping. The root issue is unsafe use of sb->s_blocksize before validation during ntfs3 mount initialization.
Mitigation direction
Apply a Linux vendor kernel update containing the referenced ntfs3 stable fixes.
Limit NTFS3 mounts to trusted administrators and trusted media.
Disable or avoid NTFS3 automount workflows if not operationally required.
Check distribution advisories for exact package names and backport status.
Validation and detection
Inventory Linux systems where ntfs3 is enabled or loadable.
Confirm kernel packages include one of the referenced stable fixes or vendor backports.
Review who can perform mounts, attach block devices, or run privileged containers.
Prioritize systems processing removable or user-supplied NTFS media.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2025-71067 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
6Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Jan 13, 2026, 15:31 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.