Description
In the Linux kernel, the following vulnerability has been resolved:

cifs: Release folio lock on fscache read hit.

Under the current code, when cifs_readpage_worker is called, the call
contract is that the callee should unlock the page. This is documented
in the read_folio section of Documentation/filesystems/vfs.rst as:

> The filesystem should unlock the folio once the read has completed,
> whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during
a read, the page lock is leaked, producing the following stack on
subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack
[<0>] folio_wait_bit_common+0x124/0x350
[<0>] filemap_read_folio+0xad/0xf0
[<0>] filemap_fault+0x8b1/0xab0
[<0>] __do_fault+0x39/0x150
[<0>] do_fault+0x25c/0x3e0
[<0>] __handle_mm_fault+0x6ca/0xc70
[<0>] handle_mm_fault+0xe9/0x350
[<0>] do_user_addr_fault+0x225/0x6c0
[<0>] exc_page_fault+0x84/0x1b0
[<0>] asm_exc_page_fault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifs_readpage_from_fscache does mark the
page clean, but does not free the folio lock. This happens in
__cifs_readpage_from_fscache on success. Releasing the lock at that
point however is not appropriate as cifs_readahead also calls
cifs_readpage_from_fscache and *does* unconditionally release the lock
after its return. This change therefore effectively makes
cifs_readpage_worker work like cifs_readahead.
Published: 2025-10-04
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
EUVD EUVD EUVD-2023-60015 In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit. Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as: > The filesystem should unlock the folio once the read has completed, > whether it was successful or not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page: $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 This requires a reboot to resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead.
History

Mon, 09 Feb 2026 22:15:00 +0000

Type Values Removed Values Added
Weaknesses NVD-CWE-noinfo
CPEs cpe:2.3:o:linux:linux_kernel:5.17:-:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc6:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc7:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:5.17:rc8:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.5:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.5:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.5:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.5:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.5:rc5:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.5:rc6:*:*:*:*:*:*

Mon, 05 Jan 2026 11:30:00 +0000


Mon, 05 Jan 2026 10:45:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

Mon, 06 Oct 2025 22:45:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

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

threat_severity

Low


Mon, 06 Oct 2025 14:45:00 +0000

Type Values Removed Values Added
First Time appeared Linux
Linux linux Kernel
Vendors & Products Linux
Linux linux Kernel

Sat, 04 Oct 2025 16:00:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit. Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as: > The filesystem should unlock the folio once the read has completed, > whether it was successful or not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page: $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 This requires a reboot to resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead.
Title cifs: Release folio lock on fscache read hit.
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T19:48:06.154Z

Reserved: 2025-10-04T15:40:38.478Z

Link: CVE-2023-53593

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2025-10-04T16:15:55.790

Modified: 2026-03-21T00:51:33.560

Link: CVE-2023-53593

cve-icon Redhat

Severity : Low

Publid Date: 2025-10-04T00:00:00Z

Links: CVE-2023-53593 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2025-10-06T14:41:15Z

Weaknesses