[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025071034-CVE-2025-38338-6aa1@gregkh>
Date: Thu, 10 Jul 2025 10:15:46 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-38338: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
From: Greg Kroah-Hartman <gregkh@...nel.org>
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.
The Linux kernel CVE team has assigned CVE-2025-38338 to this issue.
Affected and fixed versions
===========================
Issue introduced in 6.4 with commit 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 and fixed in 6.6.95 with commit 14f5549ad163be2c018abc1bb38370fff617a243
Issue introduced in 6.4 with commit 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 and fixed in 6.12.35 with commit 5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5
Issue introduced in 6.4 with commit 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 and fixed in 6.15.4 with commit 1e93b61d3eaa14bfebcc2716ac09d43f3845d420
Issue introduced in 6.4 with commit 000dbe0bec058cbf2ca9e156e4a5584f5158b0f9 and fixed in 6.16-rc1 with commit 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2025-38338
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
fs/nfs/read.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/14f5549ad163be2c018abc1bb38370fff617a243
https://git.kernel.org/stable/c/5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5
https://git.kernel.org/stable/c/1e93b61d3eaa14bfebcc2716ac09d43f3845d420
https://git.kernel.org/stable/c/4c10fa44bc5f700e2ea21de2fbae520ba21f19d9
Powered by blists - more mailing lists