CVE-2025-71201: Linux Kernel Use-After-Free Vulnerability

CVE-2025-71201 Overview

A race condition vulnerability has been identified in the Linux kernel's netfs subsystem that affects buffered read operations. The vulnerability occurs when the read result collection runs ahead of subrequest completion, causing premature page unlocking when encountering EOF (End-of-File) in the middle of a page. This allows an application to potentially access uncleared memory through memory-mapped files before the ZERO subrequest completes its tail-clearing operation.

Critical Impact

Applications may access uncleared memory content (garbage data) through mmap when reading files whose size doesn't align to page boundaries, potentially exposing sensitive kernel memory contents.

Affected Products

• Linux kernel with netfs subsystem
• Systems using AFS (Andrew File System)
• Systems using CIFS (Common Internet File System)
• Systems using 9P filesystem protocol

Discovery Timeline

• 2026-02-14 - CVE CVE-2025-71201 published to NVD
• 2026-02-18 - Last updated in NVD database

Technical Details for CVE-2025-71201

Vulnerability Analysis

This race condition vulnerability exists in the netfs_read_unlock_folios() function within the Linux kernel's netfs subsystem. The core issue stems from improper synchronization between the read result collection process and the completion of ZERO subrequests that are responsible for clearing the tail portion of pages when a file's size doesn't align with page boundaries.

When a file is read whose size falls in the middle of a page (for example, a 24998-byte file in a 4KB page system), the netfs subsystem must clear the remaining bytes to prevent information disclosure. However, the current implementation unlocks the folio (page) once the read results reach the EOF position, without waiting for the ZERO subrequest to complete its tail-clearing operation.

The vulnerability is particularly pronounced with the 9P filesystem protocol, which performs synchronous READ operations. In this case, the ZERO subrequest will always execute after the page unlock, creating a reliable window for exploitation. While AFS and CIFS typically dispatch READ operations asynchronously (allowing the ZERO subrequest to complete first), certain conditions can still trigger the vulnerability.

Root Cause

The root cause lies in netfs_read_unlock_folios() using the EOF position as the check for when to unlock a folio. The function prematurely unlocks pages when the collected read position reaches the end-of-file marker, even though additional ZERO subrequests may still be pending to clear the remainder of the page. The fix changes the end check to always use the end of the folio rather than the end of the file, ensuring all operations complete before the page becomes accessible to userspace.

Attack Vector

The vulnerability can be exploited through memory-mapped file access. An attacker or application can trigger this condition by:

1. Creating or accessing a file whose size doesn't align to page boundaries (e.g., 24998 bytes or 0x5fb2)
2. Memory-mapping the file region that includes the partial page
3. Using madvise() to manipulate page caching behavior
4. Reading the mapped region before the ZERO subrequest completes

The exploitation can be demonstrated using the xfs_io utility with commands that map a file region and read beyond the actual file content. When the race condition is triggered, the trailing bytes that should contain zeros may instead contain uninitialized memory content.

The vulnerability affects systems where synchronous read operations are performed (particularly 9P protocol) or under specific timing conditions with asynchronous protocols. The race window can be widened by manipulating system load or through deliberate delays in the netfs code path.

Detection Methods for CVE-2025-71201

Indicators of Compromise

• Unexpected non-zero data appearing in memory-mapped regions beyond file EOF boundaries
• Kernel log messages showing netfs collection state with mismatched cto (collected-to) values and outstanding ZERO subrequests
• Applications reporting inconsistent file content when using mmap-based file access
• Debug traces showing netfs_folio read-unlock events occurring before netfs_sreq ZERO TERM completion

Detection Strategies

• Monitor kernel debug output for netfs subsystem anomalies, particularly netfs_collect_folio and netfs_sreq trace messages showing out-of-order completion
• Implement file integrity monitoring for applications that use memory-mapped file I/O on 9P, AFS, or CIFS filesystems
• Review application logs for unexpected data corruption or garbage values in file trailing regions
• Enable kernel tracing for netfs operations to identify race condition timing patterns

Monitoring Recommendations

• Enable netfs kernel tracepoints (netfs_sreq, netfs_folio, netfs_collect_state) in production environments using network filesystems
• Monitor for applications performing mmap operations on remote filesystems with madvise(MADV_DONTNEED) patterns
• Implement memory content validation for security-sensitive applications using buffered reads on affected filesystems
• Set up alerts for kernel oops or warnings related to netfs page state inconsistencies

How to Mitigate CVE-2025-71201

Immediate Actions Required

• Apply the kernel patches referenced in the security advisory as soon as possible
• Consider temporarily restricting mmap access to files on affected network filesystems (9P, AFS, CIFS) until patching is complete
• Review and audit applications that use memory-mapped I/O on network filesystems for potential exposure
• Implement application-level workarounds to avoid reading beyond file boundaries through mmap

Patch Information

The vulnerability has been addressed in kernel commits that modify the folio unlock logic in netfs_read_unlock_folios(). The fix changes the end boundary check from the EOF position to the end of the folio, ensuring ZERO subrequests complete before pages are unlocked.

Relevant kernel commits:

• Linux Kernel Commit Overview - commit 570ad253a3455a520f03c2136af8714bc780186d
• Linux Kernel Commit Details - commit 5b5482c0e5ee740b35a70759d3582477aea8e8e4

System administrators should update to kernel versions containing these fixes through their distribution's package management system.

Workarounds

• Avoid using madvise(MADV_DONTNEED) in combination with mmap on affected network filesystems until the kernel is patched
• Use standard read() system calls instead of mmap for file access on 9P, AFS, or CIFS filesystems where possible
• For 9P protocol specifically, consider mounting with synchronization options that may reduce race condition windows
• Implement application-level checks to verify trailing bytes are properly zeroed when reading files with non-page-aligned sizes

# Check current kernel version for vulnerability status
uname -r

# Verify if netfs module is loaded
lsmod | grep netfs

# Check for 9P, AFS, or CIFS mounts that may be affected
mount | grep -E '9p|afs|cifs'

# Apply kernel update (Debian/Ubuntu example)
sudo apt update && sudo apt upgrade linux-image-$(uname -r)

# Apply kernel update (RHEL/CentOS example)
sudo yum update kernel