Skip to content
Fencer Vulns
medium 5.5

CVE-2023-53593 json

cifs: Release folio lock on fscache read hit.

published 2025-10-04 13 mo ago modified 2026-11-05 3 d ago also EUVD-2025-32276

cvss
5.5
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.1%
EPSS 0.1% chance of exploitation in 30 days, percentile 3%
public exploits
0
none known

Summary

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.

Patch / fix

  • Linux Linux 6.1.47, 6.4.12, 6.5
  • linux Debian 12 6.1.52-1
  • linux Debian 14, Debian 13 6.4.13-1

debian advisories DEBIAN-CVE-2023-53593

  • kernel-rt Real Time Module 15 SP6, openSUSE Leap 15.6 6.4.0-150600.10.58.1
  • kernel-syms-rt Real Time Module 15 SP6, openSUSE Leap 15.6 6.4.0-150600.10.58.1
  • kernel-rt_debug Real Time Module 15 SP6, openSUSE Leap 15.6 6.4.0-150600.10.58.1
  • kernel-source-rt Real Time Module 15 SP6, openSUSE Leap 15.6 6.4.0-150600.10.58.1
  • kernel-rt Linux Micro 6.1, Linux Micro 6.0 6.4.0-38.1
  • kernel-source-rt Linux Micro 6.1, Linux Micro 6.0 6.4.0-38.1
  • kernel-rt Real Time Module 15 SP7 6.4.0-150700.7.22.1
  • kernel-syms-rt Real Time Module 15 SP7 6.4.0-150700.7.22.1

suse advisories SUSE-SU-2025:4301-1SUSE-SU-2025:21052-1SUSE-SU-2025:21064-1SUSE-SU-2025:4189-1SUSE-SU-2025:4141-1SUSE-SU-2025:4140-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2023-53593 updated cvss 5.5

kernel: cifs: Release folio lock on fscache read hit

  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    affected: no fix available “Fix deferred”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 10 kernel
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
3 d ago

Exploit prediction

0.15% chance of exploitation in the next 30 days, higher than 3% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 5.5 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.