Back

HIGH

NFS: Fix a race when updating an existing write

Published Sep 5, 2025

Description

After nfs_lock_and_join_requests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfs_inode_remove_request() from succeeding until we actually lock the page group. The reason is that whoever called nfs_inode_remove_request() doesn't necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in nfs_lock_and_join_requests(), and hold it across the removal of the request in nfs_inode_remove_request().

Affected products

Remediation

Red Hat statement

A race condition in the NFS write path allowed a request to be removed after it was checked but before the page-group lock was taken. The fix acquires the page-group lock earlier and holds it across request removal, preventing use-after-state races. This can be triggered by a client with write access to an export and may lead to a kernel crash (remote DoS). This race condition is difficult to trigger in practice, as it requires several conditions to align (concurrent write activity and timing), and there is no evidence of remote control over memory contents. Therefore the most likely outcome is a denial of service (Availability: High), with Confidentiality and Integrity unaffected.

Red Hat mitigation

To mitigate this issue, prevent module nfs from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.

Weaknesses (1)

References (17)

Change history (0)

No recorded changes yet.

Sources
CVE.org / MITRE
Status PUBLISHED
Assigner Linux
Published Sep 5, 2025
Updated Aug 5, 2026
Reserved Apr 16, 2025
CISA Vulnrichment
Updated Jun 10, 2026
NVD
Status Modified
Modified Jul 30, 2026
Red Hat
Severity Moderate
Public date Sep 5, 2025
ENISA EUVD
Assigner Linux
Published Sep 5, 2025
Updated Aug 5, 2026
Exploited since n/a
EUVD-2025-31528