CVE-2025-71067 json
ntfs: set dummy blocksize to read boot_block when mounting
published 2026-01-13 9 mo ago modified 2026-06-17 4 mo ago also EUVD-2026-2258
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- 0.2%
- EPSS 0.2% chance of exploitation in 30 days, percentile 10%
- public exploits
- 0
- none known
Summary
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]
Patch / fix
- Linux Linux 6.1.167, 6.6.120, 6.12.64, 6.18.3, 6.19
- linux Debian 12 6.1.170-1
- linux Debian 13 6.12.69-1
- linux Debian 14 6.18.3-1
debian advisories DEBIAN-CVE-2025-71067
- linux Ubuntu 24.04 LTS 6.8.0-110.110
- linux Ubuntu 25.10 6.17.0-22.22
- linux-aws Ubuntu 24.04 LTS 6.8.0-1052.55
- linux-aws Ubuntu 25.10 6.17.0-1012.12
- linux-gcp Ubuntu 24.04 LTS 6.8.0-1054.57
- linux-gcp Ubuntu 25.10 6.17.0-1012.12
- linux-gke Ubuntu 24.04 LTS 6.8.0-1050.56
- linux-ibm Ubuntu 24.04 LTS 6.8.0-1051.51
ubuntu advisories UBUNTU-CVE-2025-71067
Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0
- git.kernel.org/stable/c/0c9327c8abf9c8f046e45008bb43d94d8ee5c6c5 commit
- git.kernel.org/stable/c/44a38eb4f7876513db5a1bccde74de9bc4389d43 commit
- git.kernel.org/stable/c/4fff9a625da958a33191c8553a03283786f9f417 commit
- git.kernel.org/stable/c/b3c151fe8f543f1a0b8b5df16ce5d97afa5ec85a commit
- git.kernel.org/stable/c/d1693a7d5a38acf6424235a6070bcf5b186a360d commit
Vendor advisories
What the vendors themselves say about their products: affected, fixed or not affected, and what to do.
red hat product security vex CVE-2025-71067 updated
kernel: ntfs: set dummy blocksize to read boot_block when mounting
-
Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more Red Hat Enterprise Linux 10 kernelnot affected: vulnerable code not present
Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf
Exploit prediction
0.20% chance of exploitation in the next 30 days, higher than 10% of all scored CVEs (FIRST EPSS, 2026-11-08).
Affected products
- Linux Linux
Classification
- Technology feeds
References
- git.kernel.org /stable/c/0c9327c8abf9c8f046e45008bb43d94d8ee5c6c5
- git.kernel.org /stable/c/44a38eb4f7876513db5a1bccde74de9bc4389d43
- git.kernel.org /stable/c/4fff9a625da958a33191c8553a03283786f9f417
- git.kernel.org /stable/c/b3c151fe8f543f1a0b8b5df16ce5d97afa5ec85a
- git.kernel.org /stable/c/d1693a7d5a38acf6424235a6070bcf5b186a360d
Sources
- CVE List CVE-2025-71067
- NVD CVE-2025-71067
Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.