CVE-2025-38338

fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()

Published Jul 10, 2025 CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Description
In the Linux kernel, the following vulnerability has been resolved:

fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()

Sometimes, when a file was read while it was being truncated by
another NFS client, the kernel could deadlock because folio_unlock()
was called twice, and the second call would XOR back the `PG_locked`
flag.

Most of the time (depending on the timing of the truncation), nobody
notices the problem because folio_unlock() gets called three times,
which flips `PG_locked` back off:

1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,
nfs_return_empty_folio
2. vfs_read, nfs_read_folio, ... netfs_read_collection,
netfs_unlock_abandoned_read_pages
3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,
nfs_return_empty_folio

The problem is that nfs_read_add_folio() is not supposed to unlock the
folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is
missing in nfs_return_empty_folio().

Rarely this leads to a warning in netfs_read_collection():

------------[ cut here ]------------
R=0000031c: folio 10 is not locked
WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00
[...]
Workqueue: events_unbound netfs_read_collection_worker
RIP: 0010:netfs_read_collection+0x7c0/0xf00
[...]
Call Trace:
<TASK>
netfs_read_collection_worker+0x67/0x80
process_one_work+0x12e/0x2c0
worker_thread+0x295/0x3a0

Most of the time, however, processes just get stuck forever in
folio_wait_bit_common(), waiting for `PG_locked` to disappear, which
never happens because nobody is really holding the folio lock.

Remediation

No solution or workaround provided in the CVE record

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
EUVD EUVD EUVD-2025-20908 In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: <TASK> netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock.
Ubuntu USN Ubuntu USN USN-7833-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-7834-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-7833-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-7833-3 Linux kernel (AWS) vulnerabilities
Ubuntu USN Ubuntu USN USN-7833-4 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-7856-1 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-1 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-2 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-1 Linux kernel (GCP) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-3 Linux kernel (Real-time) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-4 Linux kernel (FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-5 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-2 Linux kernel (GCP FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-6 Linux kernel (HWE) vulnerabilities
Ubuntu USN Ubuntu USN USN-8031-3 Linux kernel vulnerabilities
Ubuntu USN Ubuntu USN USN-8052-1 Linux kernel (Low Latency) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-7 Linux kernel (Low Latency NVIDIA) vulnerabilities
Ubuntu USN Ubuntu USN USN-8028-8 Linux kernel (IBM) vulnerabilities
Ubuntu USN Ubuntu USN USN-8052-2 Linux kernel (Xilinx) vulnerabilities
Ubuntu USN Ubuntu USN USN-8074-1 Linux kernel (Azure) vulnerabilities
Ubuntu USN Ubuntu USN USN-8074-2 Linux kernel (Azure FIPS) vulnerabilities
Ubuntu USN Ubuntu USN USN-8126-1 Linux kernel (Azure) vulnerabilities
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Type Values Removed Values Added
Weaknesses CWE-415
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Metrics cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

cvssV3_1

{'score': 7.8, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H'}

Type Values Removed Values Added
Metrics epss

{'score': 0.00018}

epss

{'score': 0.00023}

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: <TASK> netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock.
Title fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
References
Weaknesses

Sources

Status
PUBLISHED
Assigner
Linux
Published
Updated
Nov 5, 2026, 9:02 PM
Reserved
Apr 16, 2025, 4:51 AM
Status
Analyzed
Published
Jul 10, 2025, 9:15 AM
Modified
Nov 5, 2026, 9:18 PM
Severity
Moderate
Public date
Jul 10, 2025, 12:00 AM