In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between balance and cancel/pause Syzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: <TASK> btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The reproducer is running a balance and a cancel or pause in parallel. The way balance finishes is a bit wonky, if we were paused we need to save the balance_ctl in the fs_info, but clear it otherwise and cleanup. However we rely on the return values being specific errors, or having a cancel request or no pause request. If balance completes and returns 0, but we have a pause or cancel request we won't do the appropriate cleanup, and then the next time we try to start a balance we'll trip this ASSERT. The error handling is just wrong here, we always want to clean up, unless we got -ECANCELLED and we set the appropriate pause flag in the exclusive op. With this patch the reproducer ran for an hour without tripping, previously it would trip in less than a few minutes.
総合評価: CVE-2023-54023 は低リスク(5.1/100)。悪用される可能性が高い(EPSS 0.15%、5 パーセンタイル) 推奨対応: 総合リスクは低く緊急対応は不要です。通常の保守サイクルでパッチを適用し、CVSS / EPSS が上昇したら優先度を見直してください。
リスクは変動します。再評価に基づき、本ページの表示内容を更新しています。
EPSS は日次で悪用されやすさの相対度合いを推定します。パーセンタイルは採点済み CVE の中での相対位置(高いほど相対的に深刻)を示します。
| # | 日付 | 旧 EPSS スコア | 新 EPSS スコア | Δ(新 − 旧) |
|---|---|---|---|---|
| 1 | 2026-06-15 | 0.02% | 0.15% | +0.14% |
| 2 | 2025-12-24 | — | 0.02% | — |
EPSS の全履歴 (全 2 件)
この CVE の CVSS 指標。
この CVE のデータセットに CVSS はありません。
| vendor | priority | summary | link |
|---|---|---|---|
debian
|
not yet assigned | CVE-2023-54023 not yet assigned priority: Debian including 1 source packages (linux), 5 status rows across 5 suites (bookworm, bullseye, forky, sid, trixie): resolved 4, open 1. | https://security-tracker.debian.org/tracker/CVE-2023-54023 |
redhat
|
low | — | https://access.redhat.com/security/cve/CVE-2023-54023 |
suse
|
medium | CVE-2023-54023 severity moderate: SUSE including 365 source package names (2.1.3-6.115:kernel-default-base-6.4.0-39.1.21.16, 2.1.3-7.146:kernel-rt-6.4.0-40.1, …), 668 product×package rows across 131 product lines (Container suse/sl-micro/6.0/base-os-container, Container suse/sl-micro/6.0/kvm-os-container, … (131 product lines)): Fixed 385, Known Affected 231, Known Not Affected 33, Will Not Fix 19. | https://www.suse.com/security/cve/CVE-2023-54023/ |
ubuntu
|
medium | CVE-2023-54023 medium priority: Ubuntu including 157 source packages (linux, linux-allwinner-5.19, …), 1405 status rows across 9 suites (bionic, focal, jammy, noble, plucky, questing, trusty, upstream, xenial): DNE 1010, ignored 177, released 83, needed 75, not-affected 60. | https://ubuntu.com/security/CVE-2023-54023 |
| ベンダー | 製品 | バージョン | 生の CPE |
|---|---|---|---|
| linux | linux_kernel | >= 3.3, < 6.1.42 | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| linux | linux_kernel | >= 3.3, < 6.4.7 | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| linux | linux_kernel | >= 3.3, < 6.5 | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |