CVE-2025-71067: Linux Kernel NTFS Privilege Escalation

CVE-2025-71067 Overview

A vulnerability has been identified in the Linux kernel's NTFS3 filesystem driver where an uninitialized or zero block size (sb->s_blocksize) is used when attempting to read the boot block during mount operations. This issue occurs because the superblock's block size is not properly defined or validated before being used in ntfs_init_from_boot(), leading to potential system instability or kernel bugs.

Critical Impact
An attacker with local access can trigger kernel bugs by manipulating block device sizes before mounting NTFS3 filesystems, potentially leading to denial of service or system instability.

Affected Products

Linux Kernel (NTFS3 filesystem driver)
Systems with NTFS3 mount capabilities enabled
Block devices with configurable block sizes

Discovery Timeline

2026-01-13 - CVE CVE-2025-71067 published to NVD
2026-01-13 - Last updated in NVD database

Technical Details for CVE-2025-71067

Vulnerability Analysis

This vulnerability stems from improper initialization of the filesystem superblock's block size parameter during the NTFS3 mount process. When a user mounts an NTFS3 filesystem, the kernel's get_tree_bdev_flags() function attempts to set the superblock block size via sb_set_blocksize(sb, block_size(bdev)). However, when the underlying block device's block size exceeds PAGE_SIZE (typically 4096 bytes on most systems), the sb_set_blocksize() function fails silently, leaving sb->s_blocksize at zero.

Subsequently, ntfs_init_from_boot() attempts to read the boot block using this uninitialized block size value, triggering a kernel bug condition. This represents an input validation failure in the mount path where boundary conditions for block size are not properly enforced.

Root Cause

The root cause is a missing validation and fallback mechanism in the NTFS3 filesystem driver's mount code path. The driver assumes sb_set_blocksize() will always succeed but does not handle the case where the block device's block size exceeds PAGE_SIZE. When this happens, the superblock's s_blocksize field remains at its default zero value, which is then used without verification to perform I/O operations for reading the boot block.

The fix involves setting a dummy (valid) block size before attempting to read the boot block, ensuring that even if the initial sb_set_blocksize() call fails, there is a safe fallback value in place.

Attack Vector

The vulnerability can be triggered through a local attack requiring the ability to manipulate block device properties and mount filesystems. The attack sequence involves:

Creating or accessing a block device (such as a null block device)
Using ioctl$FS_IOC_SETFLAGS to set the block device's block size to a value greater than PAGE_SIZE (e.g., 16384 bytes)
Attempting to mount an NTFS3 filesystem on this device
The mount operation triggers the bug when ntfs_init_from_boot() attempts to read with a zero block size

The vulnerability requires local access and specific privileges to manipulate block device settings and perform mount operations.

Detection Methods for CVE-2025-71067

Indicators of Compromise

Kernel panic or bug messages referencing ntfs_init_from_boot() function
System logs showing NTFS3 mount failures with block size related errors
Evidence of ioctl calls setting unusual block device sizes prior to mount attempts
Crash dumps indicating null or zero value dereference in filesystem mounting code

Detection Strategies

Monitor for ioctl system calls with FS_IOC_SETFLAGS that set block sizes exceeding PAGE_SIZE
Implement kernel audit rules to track mount operations on NTFS3 filesystems
Use kernel debugging tools to detect zero block size conditions during filesystem operations
Deploy SentinelOne Singularity XDR to detect anomalous block device manipulation sequences

Monitoring Recommendations

Enable kernel logging for filesystem mount operations and errors
Configure auditd rules to track mount syscalls with ntfs3 filesystem type
Monitor system stability metrics for unexpected kernel panics or crashes
Implement alerting for unusual block device configuration changes

How to Mitigate CVE-2025-71067

Immediate Actions Required

Apply the latest kernel patches containing the NTFS3 block size validation fix
Consider disabling NTFS3 filesystem support if not required (modprobe -r ntfs3)
Restrict access to block device manipulation capabilities to trusted users only
Review and limit mount permissions in production environments

Patch Information

Multiple kernel commits have been released to address this vulnerability by setting a dummy block size before reading the boot block. The patches ensure proper return value handling and add appropriate validation. The following commits contain the fix:

Update to a kernel version containing these fixes as soon as possible.

Workarounds

Disable NTFS3 module loading by blacklisting the module: add blacklist ntfs3 to /etc/modprobe.d/blacklist.conf
Use alternative NTFS drivers (ntfs-3g via FUSE) if NTFS support is required
Restrict CAP_SYS_ADMIN capability to prevent unauthorized mount operations
Implement SELinux or AppArmor policies to restrict block device ioctl operations

bash

# Disable NTFS3 kernel module
echo "blacklist ntfs3" >> /etc/modprobe.d/blacklist-ntfs3.conf
echo "install ntfs3 /bin/false" >> /etc/modprobe.d/blacklist-ntfs3.conf

# Unload if currently loaded
modprobe -r ntfs3

# Update initramfs to persist changes
update-initramfs -u