{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2023-52982", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2025-03-27T16:40:15.740Z", "datePublished": "2025-03-27T16:43:20.735Z", "dateUpdated": "2025-05-04T07:46:47.540Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-05-04T07:46:47.540Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Use wait_on_bit() to wait for the freeing of relinquished volume\n\nThe freeing of relinquished volume will wake up the pending volume\nacquisition by using wake_up_bit(), however it is mismatched with\nwait_var_event() used in fscache_wait_on_volume_collision() and it will\nnever wake up the waiter in the wait-queue because these two functions\noperate on different wait-queues.\n\nAccording to the implementation in fscache_wait_on_volume_collision(),\nif the wake-up of pending acquisition is delayed longer than 20 seconds\n(e.g., due to the delay of on-demand fd closing), the first\nwait_var_event_timeout() will timeout and the following wait_var_event()\nwill hang forever as shown below:\n\n FS-Cache: Potential volume collision new=00000024 old=00000022\n ......\n INFO: task mount:1148 blocked for more than 122 seconds.\n Not tainted 6.1.0-rc6+ #1\n task:mount state:D stack:0 pid:1148 ppid:1\n Call Trace:\n <TASK>\n __schedule+0x2f6/0xb80\n schedule+0x67/0xe0\n fscache_wait_on_volume_collision.cold+0x80/0x82\n __fscache_acquire_volume+0x40d/0x4e0\n erofs_fscache_register_volume+0x51/0xe0 [erofs]\n erofs_fscache_register_fs+0x19c/0x240 [erofs]\n erofs_fc_fill_super+0x746/0xaf0 [erofs]\n vfs_get_super+0x7d/0x100\n get_tree_nodev+0x16/0x20\n erofs_fc_get_tree+0x20/0x30 [erofs]\n vfs_get_tree+0x24/0xb0\n path_mount+0x2fa/0xa90\n do_mount+0x7c/0xa0\n __x64_sys_mount+0x8b/0xe0\n do_syscall_64+0x30/0x60\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nConsidering that wake_up_bit() is more selective, so fix it by using\nwait_on_bit() instead of wait_var_event() to wait for the freeing of\nrelinquished volume. In addition because waitqueue_active() is used in\nwake_up_bit() and clear_bit() doesn't imply any memory barrier, use\nclear_and_wake_up_bit() to add the missing memory barrier between\ncursor->flags and waitqueue_active()."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/fscache/volume.c"], "versions": [{"version": "62ab63352350e881ae693a8236b35d7d0516c78b", "lessThan": "3be069f42a7b79d3149194f21cdf24bf23864cac", "status": "affected", "versionType": "git"}, {"version": "62ab63352350e881ae693a8236b35d7d0516c78b", "lessThan": "8226e37d82f43657da34dd770e2b38f20242ada7", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/fscache/volume.c"], "versions": [{"version": "5.17", "status": "affected"}, {"version": "0", "lessThan": "5.17", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.11", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.2", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.17", "versionEndExcluding": "6.1.11"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.17", "versionEndExcluding": "6.2"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/3be069f42a7b79d3149194f21cdf24bf23864cac"}, {"url": "https://git.kernel.org/stable/c/8226e37d82f43657da34dd770e2b38f20242ada7"}], "title": "fscache: Use wait_on_bit() to wait for the freeing of relinquished volume", "x_generator": {"engine": "bippy-1.2.0"}}}}

{}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Use wait_on_bit() to wait for the freeing of relinquished volume\n\nThe freeing of relinquished volume will wake up the pending volume\nacquisition by using wake_up_bit(), however it is mismatched with\nwait_var_event() used in fscache_wait_on_volume_collision() and it will\nnever wake up the waiter in the wait-queue because these two functions\noperate on different wait-queues.\n\nAccording to the implementation in fscache_wait_on_volume_collision(),\nif the wake-up of pending acquisition is delayed longer than 20 seconds\n(e.g., due to the delay of on-demand fd closing), the first\nwait_var_event_timeout() will timeout and the following wait_var_event()\nwill hang forever as shown below:\n\n FS-Cache: Potential volume collision new=00000024 old=00000022\n ......\n INFO: task mount:1148 blocked for more than 122 seconds.\n Not tainted 6.1.0-rc6+ #1\n task:mount state:D stack:0 pid:1148 ppid:1\n Call Trace:\n <TASK>\n __schedule+0x2f6/0xb80\n schedule+0x67/0xe0\n fscache_wait_on_volume_collision.cold+0x80/0x82\n __fscache_acquire_volume+0x40d/0x4e0\n erofs_fscache_register_volume+0x51/0xe0 [erofs]\n erofs_fscache_register_fs+0x19c/0x240 [erofs]\n erofs_fc_fill_super+0x746/0xaf0 [erofs]\n vfs_get_super+0x7d/0x100\n get_tree_nodev+0x16/0x20\n erofs_fc_get_tree+0x20/0x30 [erofs]\n vfs_get_tree+0x24/0xb0\n path_mount+0x2fa/0xa90\n do_mount+0x7c/0xa0\n __x64_sys_mount+0x8b/0xe0\n do_syscall_64+0x30/0x60\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nConsidering that wake_up_bit() is more selective, so fix it by using\nwait_on_bit() instead of wait_var_event() to wait for the freeing of\nrelinquished volume. In addition because waitqueue_active() is used in\nwake_up_bit() and clear_bit() doesn't imply any memory barrier, use\nclear_and_wake_up_bit() to add the missing memory barrier between\ncursor->flags and waitqueue_active()."}], "id": "CVE-2023-52982", "lastModified": "2025-03-28T18:11:49.747", "metrics": {}, "published": "2025-03-27T17:15:45.437", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/3be069f42a7b79d3149194f21cdf24bf23864cac"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/8226e37d82f43657da34dd770e2b38f20242ada7"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: fscache: Use wait_on_bit() to wait for the freeing of relinquished volume", "id": "2355522", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2355522"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\nfscache: Use wait_on_bit() to wait for the freeing of relinquished volume\nThe freeing of relinquished volume will wake up the pending volume\nacquisition by using wake_up_bit(), however it is mismatched with\nwait_var_event() used in fscache_wait_on_volume_collision() and it will\nnever wake up the waiter in the wait-queue because these two functions\noperate on different wait-queues.\nAccording to the implementation in fscache_wait_on_volume_collision(),\nif the wake-up of pending acquisition is delayed longer than 20 seconds\n(e.g., due to the delay of on-demand fd closing), the first\nwait_var_event_timeout() will timeout and the following wait_var_event()\nwill hang forever as shown below:\nFS-Cache: Potential volume collision new=00000024 old=00000022\n......\nINFO: task mount:1148 blocked for more than 122 seconds.\nNot tainted 6.1.0-rc6+ #1\ntask:mount state:D stack:0 pid:1148 ppid:1\nCall Trace:\n<TASK>\n__schedule+0x2f6/0xb80\nschedule+0x67/0xe0\nfscache_wait_on_volume_collision.cold+0x80/0x82\n__fscache_acquire_volume+0x40d/0x4e0\nerofs_fscache_register_volume+0x51/0xe0 [erofs]\nerofs_fscache_register_fs+0x19c/0x240 [erofs]\nerofs_fc_fill_super+0x746/0xaf0 [erofs]\nvfs_get_super+0x7d/0x100\nget_tree_nodev+0x16/0x20\nerofs_fc_get_tree+0x20/0x30 [erofs]\nvfs_get_tree+0x24/0xb0\npath_mount+0x2fa/0xa90\ndo_mount+0x7c/0xa0\n__x64_sys_mount+0x8b/0xe0\ndo_syscall_64+0x30/0x60\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\nConsidering that wake_up_bit() is more selective, so fix it by using\nwait_on_bit() instead of wait_var_event() to wait for the freeing of\nrelinquished volume. In addition because waitqueue_active() is used in\nwake_up_bit() and clear_bit() doesn't imply any memory barrier, use\nclear_and_wake_up_bit() to add the missing memory barrier between\ncursor->flags and waitqueue_active()."], "name": "CVE-2023-52982", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2025-03-27T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2023-52982\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-52982\nhttps://lore.kernel.org/linux-cve-announce/2025032706-CVE-2023-52982-7291@gregkh/T"], "threat_severity": "Low"}