fkie_cve-2023-53593
Vulnerability from fkie_nvd
Published
2025-10-04 16:15
Modified
2025-10-06 14:56
Severity ?
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Release folio lock on fscache read hit.\n\nUnder the current code, when cifs_readpage_worker is called, the call\ncontract is that the callee should unlock the page. This is documented\nin the read_folio section of Documentation/filesystems/vfs.rst as:\n\n\u003e The filesystem should unlock the folio once the read has completed,\n\u003e whether it was successful or not.\n\nWithout this change, when fscache is in use and cache hit occurs during\na read, the page lock is leaked, producing the following stack on\nsubsequent reads (via mmap) to the page:\n\n$ cat /proc/3890/task/12864/stack\n[\u003c0\u003e] folio_wait_bit_common+0x124/0x350\n[\u003c0\u003e] filemap_read_folio+0xad/0xf0\n[\u003c0\u003e] filemap_fault+0x8b1/0xab0\n[\u003c0\u003e] __do_fault+0x39/0x150\n[\u003c0\u003e] do_fault+0x25c/0x3e0\n[\u003c0\u003e] __handle_mm_fault+0x6ca/0xc70\n[\u003c0\u003e] handle_mm_fault+0xe9/0x350\n[\u003c0\u003e] do_user_addr_fault+0x225/0x6c0\n[\u003c0\u003e] exc_page_fault+0x84/0x1b0\n[\u003c0\u003e] asm_exc_page_fault+0x27/0x30\n\nThis requires a reboot to resolve; it is a deadlock.\n\nNote however that the call to cifs_readpage_from_fscache does mark the\npage clean, but does not free the folio lock. This happens in\n__cifs_readpage_from_fscache on success. Releasing the lock at that\npoint however is not appropriate as cifs_readahead also calls\ncifs_readpage_from_fscache and *does* unconditionally release the lock\nafter its return. This change therefore effectively makes\ncifs_readpage_worker work like cifs_readahead."
}
],
"id": "CVE-2023-53593",
"lastModified": "2025-10-06T14:56:21.733",
"metrics": {},
"published": "2025-10-04T16:15:55.790",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/4259dd534245579c966c53c15187cc8e9461d6e9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/5a87735675147f848445f05fd1f06168188f91af"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/69513dd669e243928f7450893190915a88f84a2b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6e74926ede96470be84e66a1c576982fe4f8ea79"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/7a9fb689c1a1dc373887621a3bfa3810df0abde4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/961f7ce16223aee2db583a43877d84e6d1f2b857"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9e725386d4262ef23ae51993f04602bc535b5be2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/c3ac8323f2f5b50e32681c254b8318f7fa2dc3f4"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…