{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.11-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.11-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.11-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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:   \u003cTASK\u003e   __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-\u003eflags and waitqueue_active().",
  "id": "DEBIAN-CVE-2023-52982",
  "modified": "2026-04-28T19:53:23.687399410Z",
  "published": "2025-03-27T17:15:45.437Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2023-52982"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2023-52982"
  ]
}