CVE-2023-53593
published 2025-10-04CVE-2023-53593: In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit. Under the current code, when…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
3.4th percentile
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
[] folio_wait_bit_common+0x124/0x350
[] filemap_read_folio+0xad/0xf0
[] filemap_fault+0x8b1/0xab0
[] __do_fault+0x39/0x150
[] do_fault+0x25c/0x3e0
[] __handle_mm_fault+0x6ca/0xc70
[] handle_mm_fault+0xe9/0x350
[] do_user_addr_fault+0x225/0x6c0
[] exc_page_fault+0x84/0x1b0
[] 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.
Affected
13 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.52-1 (bookworm) | linux 6.1.52-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 0174ee9947bd0f24fee2794b35258960d108b7aa < 9e725386d4262ef23ae51993f04602bc535b5be2 | 9e725386d4262ef23ae51993f04602bc535b5be2 |
| linux | linux | >= 0174ee9947bd0f24fee2794b35258960d108b7aa < 7a9fb689c1a1dc373887621a3bfa3810df0abde4 | 7a9fb689c1a1dc373887621a3bfa3810df0abde4 |
| linux | linux | >= 0174ee9947bd0f24fee2794b35258960d108b7aa < 69513dd669e243928f7450893190915a88f84a2b | 69513dd669e243928f7450893190915a88f84a2b |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.197-1 | 5.10.197-1 |
| linux | linux_kernel | >= 0 < 6.1.52-1 | 6.1.52-1 |
| linux | linux_kernel | >= 0 < 6.4.13-1 | 6.4.13-1 |
| linux | linux_kernel | >= 0 < 6.4.13-1 | 6.4.13-1 |
| linux | linux_kernel | >= 5.17.1 < 6.1.47 | 6.1.47 |
| linux | linux_kernel | >= 6.2 < 6.4.12 | 6.4.12 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: cifs: Release folio lock on fscache read hit
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2023-53593 [MEDIUM] CWE-772 kernel: cifs: Release folio lock on fscache read hit
kernel: cifs: Release folio lock on fscache read hit
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
[] folio_wait_bit_common+0x124/0x350
[] filemap_read_folio+0xad/0xf0
[] filemap_fault+0x8b1/0xab0
[] __do
Debian
CVE-2023-53593: linux - In the Linux kernel, the following vulnerability has been resolved: cifs: Relea...
vendor_debian·2023·CVSS 5.5
CVE-2023-53593 [MEDIUM] CVE-2023-53593: linux - In the Linux kernel, the following vulnerability has been resolved: cifs: Relea...
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 [] folio_wait_bit_common+0x124/0x350 [] filemap_read_folio+0xad/0xf0 [] filemap_fault+0x8b1/0xab0 [] __do_fault+0x39/0x150 [] do_fault+0x25c/0x3e0 [] __handle_
VulDB
Linux Kernel up to 6.4.11 vfs.rst cifs_readpage_worker deadlock (EUVD-2023-60015 / Nessus ID 276910)
vuldb·2026-04-28·CVSS 5.5
CVE-2023-53593 [MEDIUM] Linux Kernel up to 6.4.11 vfs.rst cifs_readpage_worker deadlock (EUVD-2023-60015 / Nessus ID 276910)
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.4.11. This affects the function cifs_readpage_worker of the file Documentation/filesystems/vfs.rst. Performing a manipulation results in deadlock.
This vulnerability was named CVE-2023-53593. The attack needs to be approached within the local network. There is no available exploit.
It is advisable to upgrade the affected component.
OSV
CVE-2023-53593: In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit
osv·2025-10-04·CVSS 5.5
CVE-2023-53593 [MEDIUM] CVE-2023-53593: In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit
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 [] folio_wait_bit_common+0x124/0x350 [] filemap_read_folio+0xad/0xf0 [] filemap_fault+0x8b1/0xab0 [] __do_fault+0x39/0x150 [] do_fault+0x25c/0x3e0 [] __handle_
GHSA
GHSA-c98j-hghp-fmxr: In the Linux kernel, the following vulnerability has been resolved:
cifs: Release folio lock on fscache read hit
ghsa_unreviewed·2025-10-04
CVE-2023-53593 [MEDIUM] GHSA-c98j-hghp-fmxr: In the Linux kernel, the following vulnerability has been resolved:
cifs: Release folio lock on fscache read hit
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
[] folio_wait_bit_common+0x124/0x350
[] filemap_read_folio+0xad/0xf0
[] filemap_fault+0x8b1/0xab0
[] __do_fault+0x39/0x150
[] do_fault+0x25c/0x3e0
[] __ha
No detection rules found.
No public exploits indexed.
2025-10-04
Published