CVE-2023-52982
published 2025-03-27CVE-2023-52982: In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.21%
11.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
The freeing of relinquished volume will wake up the pending volume
acquisition by using wake_up_bit(), however it is mismatched with
wait_var_event() used in fscache_wait_on_volume_collision() and it will
never wake up the waiter in the wait-queue because these two functions
operate on different wait-queues.
According to the implementation in fscache_wait_on_volume_collision(),
if the wake-up of pending acquisition is delayed longer than 20 seconds
(e.g., due to the delay of on-demand fd closing), the first
wait_var_event_timeout() will timeout and the following wait_var_event()
will hang forever as shown below:
FS-Cache: Potential volume collision new=00000024 old=00000022
......
INFO: task mount:1148 blocked for more than 122 seconds.
Not tainted 6.1.0-rc6+ #1
task:mount state:D stack:0 pid:1148 ppid:1
Call Trace:
__schedule+0x2f6/0xb80
schedule+0x67/0xe0
fscache_wait_on_volume_collision.cold+0x80/0x82
__fscache_acquire_volume+0x40d/0x4e0
erofs_fscache_register_volume+0x51/0xe0 [erofs]
erofs_fscache_register_fs+0x19c/0x240 [erofs]
erofs_fc_fill_super+0x746/0xaf0 [erofs]
vfs_get_super+0x7d/0x100
get_tree_nodev+0x16/0x20
erofs_fc_get_tree+0x20/0x30 [erofs]
vfs_get_tree+0x24/0xb0
path_mount+0x2fa/0xa90
do_mount+0x7c/0xa0
__x64_sys_mount+0x8b/0xe0
do_syscall_64+0x30/0x60
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Considering that wake_up_bit() is more selective, so fix it by using
wait_on_bit() instead of wait_var_event() to wait for the freeing of
relinquished volume. In addition because waitqueue_active() is used in
wake_up_bit() and clear_bit() doesn't imply any memory barrier, use
clear_and_wake_up_bit() to add the missing memory barrier between
cursor->flags and waitqueue_active().
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.11-1 (bookworm) | linux 6.1.11-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 62ab63352350e881ae693a8236b35d7d0516c78b < 3be069f42a7b79d3149194f21cdf24bf23864cac | 3be069f42a7b79d3149194f21cdf24bf23864cac |
| linux | linux | >= 62ab63352350e881ae693a8236b35d7d0516c78b < 8226e37d82f43657da34dd770e2b38f20242ada7 | 8226e37d82f43657da34dd770e2b38f20242ada7 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.11-1 | 6.1.11-1 |
| linux | linux_kernel | >= 0 < 6.1.11-1 | 6.1.11-1 |
| linux | linux_kernel | >= 0 < 6.1.11-1 | 6.1.11-1 |
| linux | linux_kernel | >= 5.17 < 6.1.11 | 6.1.11 |
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.
OSV
CVE-2023-52982: In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The free
osv·2025-03-27·CVSS 5.5
CVE-2023-52982 [MEDIUM] CVE-2023-52982: In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The free
In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision n
GHSA
GHSA-3cvm-96rv-2mw4: In the Linux kernel, the following vulnerability has been resolved:
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
The fr
ghsa_unreviewed·2025-03-27
CVE-2023-52982 [MEDIUM] GHSA-3cvm-96rv-2mw4: In the Linux kernel, the following vulnerability has been resolved:
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
The fr
In the Linux kernel, the following vulnerability has been resolved:
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
The freeing of relinquished volume will wake up the pending volume
acquisition by using wake_up_bit(), however it is mismatched with
wait_var_event() used in fscache_wait_on_volume_collision() and it will
never wake up the waiter in the wait-queue because these two functions
operate on different wait-queues.
According to the implementation in fscache_wait_on_volume_collision(),
if the wake-up of pending acquisition is delayed longer than 20 seconds
(e.g., due to the delay of on-demand fd closing), the first
wait_var_event_timeout() will timeout and the following wait_var_event()
will hang forever as shown below:
FS-Cache: Potential volume collisi
Red Hat
kernel: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
vendor_redhat·2025-03-27·CVSS 5.5
CVE-2023-52982 [MEDIUM] CWE-821 kernel: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
kernel: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
In the Linux kernel, the following vulnerability has been resolved:
fscache: Use wait_on_bit() to wait for the freeing of relinquished volume
The freeing of relinquished volume will wake up the pending volume
acquisition by using wake_up_bit(), however it is mismatched with
wait_var_event() used in fscache_wait_on_volume_collision() and it will
never wake up the waiter in the wait-queue because these two functions
operate on different wait-queues.
According to the implementation in fscache_wait_on_volume_collision(),
if the wake-up of pending acquisition is delayed longer than 20 seconds
(e.g., due to the delay of on-demand fd closing), the first
wait_var_event_timeout() will timeout and the following wait_v
Debian
CVE-2023-52982: linux - In the Linux kernel, the following vulnerability has been resolved: fscache: Us...
vendor_debian·2023·CVSS 5.5
CVE-2023-52982 [MEDIUM] CVE-2023-52982: linux - In the Linux kernel, the following vulnerability has been resolved: fscache: Us...
In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues. According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision n
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2025-03-27
Published