---
id: CVE-2023-52982
title: 'fscache: Use wait_on_bit() to wait for the freeing of relinquished volume'
summary: |-
  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_…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 62ab63352350e881ae693a8236b35d7d0516c78b <
    3be069f42a7b79d3149194f21cdf24bf23864cac
  - >-
    Linux >= 62ab63352350e881ae693a8236b35d7d0516c78b <
    8226e37d82f43657da34dd770e2b38f20242ada7
  - Linux 5.17
ssvc:
  exploitation: none
  automatable: 'no'
  technicalImpact: partial
  timestamp: '2026-11-05T20:14:04.230900Z'
published: '2025-03-27'
updated: '2026-11-05'
sourceUpdated: '2026-11-05T20:20:53.280Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2023-52982'
references:
  - url: 'https://git.kernel.org/stable/c/3be069f42a7b79d3149194f21cdf24bf23864cac'
  - url: 'https://git.kernel.org/stable/c/8226e37d82f43657da34dd770e2b38f20242ada7'
tags:
  - cve.org
epss: 0.00228
epssPercentile: 0.13694
ingestedAt: '2026-11-05T22:38:31.750Z'
---

## Overview

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().

## Affected

- `Linux >= 62ab63352350e881ae693a8236b35d7d0516c78b < 3be069f42a7b79d3149194f21cdf24bf23864cac`
- `Linux >= 62ab63352350e881ae693a8236b35d7d0516c78b < 8226e37d82f43657da34dd770e2b38f20242ada7`
- `Linux 5.17`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.