CVE-2025-71067 in Linux
Summary
by MITRE • 01/13/2026
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.
[[email protected]: changed comment style, added
return value handling]
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 04/19/2026
The vulnerability identified as CVE-2025-71067 resides within the Linux kernel's ntfs3 filesystem driver, specifically during the mount operation process. This issue demonstrates a critical flaw in how the kernel handles block size initialization when reading boot sectors, creating potential for system instability and security risks. The vulnerability manifests when attempting to mount an ntfs3 filesystem where the underlying block device has a block size exceeding the system's page size, leading to improper initialization of the superblock's block size parameter.
The technical root cause involves the ntfs3 filesystem driver's failure to properly validate or initialize the superblock's block size parameter before attempting to read the boot sector. During the mount process, the system calls get_tree_bdev_flags() which should set the superblock block size using sb_set_blocksize() based on the underlying block device's characteristics. However, when the block device's block size exceeds PAGE_SIZE, the sb_set_blocksize() function fails to properly set the superblock's block size, leaving it at zero. This zero value subsequently causes ntfs_init_from_boot() to attempt reading the boot_block with an invalid block size parameter, resulting in undefined behavior and potential system crashes.
This vulnerability presents significant operational impact as it can be triggered through a specific sequence involving nullb device manipulation and ioctl operations that set the block size to values exceeding standard page boundaries. The syz reproducer demonstrates how an attacker could leverage this flaw by creating a nullb device with a large block size, then attempting to mount it as an ntfs3 filesystem. The attack vector aligns with ATT&CK technique T1059.001 for command execution and T1490 for data destruction, as the vulnerability could potentially be exploited to cause system instability or data corruption. The flaw represents a classic case of uninitialized memory access and improper input validation, which maps to CWE-457: Use of Uninitialized Variable and CWE-665: Improper Initialization.
The mitigation strategy requires ensuring that the superblock block size is properly initialized before attempting boot sector operations, regardless of the underlying block device characteristics. Kernel developers should implement robust validation checks that guarantee sb->s_blocksize is properly set to a valid value before any boot sector reading operations commence. This fix should include explicit handling of edge cases where block device sizes exceed system page boundaries, ensuring that appropriate default values or error conditions are properly managed. The solution should also incorporate defensive programming practices that prevent uninitialized variable usage and ensure proper parameter validation throughout the mount process. Additionally, implementing proper error handling and return value checking in the ntfs3 driver would prevent the propagation of invalid block size values and maintain system stability during filesystem operations.