Answer in brief
CVE-2023-52982 records a Medium severity (CVSS 5.5) vulnerability in fscache: Use wait_on_bit() to wait for the freeing of relinquished volume. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.2:rc5:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:6.2:rc6:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=62ab63352350e881ae693a8236b35d7d0516c78b <3be069f42a7b79d3149194f21cdf24bf23864cac || >=62ab63352350e881ae693a8236b35d7d0516c78b <8226e37d82f43657da34dd770e2b38f20242ada7 | 3be069f42a7b79d3149194f21cdf24bf23864cac, 8226e37d82f43657da34dd770e2b38f20242ada7 |
| Linux/Linuxgeneric | 5.17 | Not reported |
Published upstream
Mar 27, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 5, 2026
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: <TASK> __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().
Quoted source text, attributed separately from HOL analysis.