CVE-2026-31519 | btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create

In the Linux kernel, the following vulnerability has been resolved: btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create We have recently observed a number of subvolumes with broken dentries. ls-ing the parent dir looks like: drwxrwxrwt 1 root root 16 Jan 23 16:49 . drwxr-xr-x 1 root root 24 Jan 23 16:48 .. d????????? ? ? ? ? ? broken_subvol and similarly stat-ing the file fails. In this state, deleting the subvol fails with ENOENT, but attempting to create a new file or subvol over it errors out with EEXIST and even aborts the fs. Which leaves us a bit stuck. dmesg contains a single notable error message reading: "could not do orphan cleanup -2" 2 is ENOENT and the error comes from the failure handling path of btrfs_orphan_cleanup(), with the stack leading back up to btrfs_lookup(). btrfs_lookup btrfs_lookup_dentry btrfs_orphan_cleanup // prints that message and returns -ENOENT After some detailed inspection of the internal state, it became clear that: - there are no orphan items for the subvol - the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc. - the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later. - after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want. i.e., btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume btrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) on the root when it runs, so it cannot run more than once on a given root, so something else must run concurrently. However, the obvious routes to deleting an orphan when nlinks goes to 0 should not be able to run without first doing a lookup into the subvolume, which should run btrfs_orphan_cleanup() and set the bit. The final important observation is that create_subvol() calls d_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if the dentry cache gets dropped, the next lookup into the subvolume will make a real call into btrfs_orphan_cleanup() for the first time. This opens up the possibility of concurrently deleting the inode/orphan items but most typical evict() paths will be holding a reference on the parent dentry (child dentry holds parent->d_lockref.count via dget in d_alloc(), released in __dentry_kill()) and prevent the parent from being removed from the dentry cache. The one exception is delayed iputs. Ordered extent creation calls igrab() on the inode. If the file is unlinked and closed while those refs are held, iput() in __dentry_kill() decrements i_count but does not trigger eviction (i_count > 0). The child dentry is freed and the subvol dentry's d_lockref.count drops to 0, making it evictable while the inode is still alive. Since there are two races (the race between writeback and unlink and the race between lookup and delayed iputs), and there are too many moving parts, the following three diagrams show the complete picture. (Only the second and third are races) Phase 1: Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set btrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c ---truncated---

公開： 2026-04-22 最終更新： 2026-06-17 Assigner： 416baaa9-dc9f-4396-8d5f-8c081fb06d67 ソース： 416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD ステータス：Analyzed，CVE の状態： published
参照： NVD, CVE.org, EUVD, JVN

CVE-2026-31519 は低リスク（22.9/100）。CVSS 深刻度は中。悪用される可能性が高い（EPSS 0.12%、2 パーセンタイル） 悪用情報と EPSS の推移を監視し、必要に応じて優先度を見直してください。

リスクは変動します。再評価に基づき、本ページの表示内容を更新しています。

CVE-2026-31519 の EPSS（Exploit Prediction Scoring System）スコア

EPSS は日次で悪用されやすさの相対度合いを推定します。パーセンタイルは採点済み CVE の中での相対位置（高いほど相対的に深刻）を示します。

# 日付 旧 EPSS スコア 新 EPSS スコア Δ（新 − 旧）
1 2026-06-15 0.02% 0.12% +0.10%
2 2026-04-23 — 0.02% —

EPSS の全履歴 （全 2 件）

CVE-2026-31519 の CVSS（Common Vulnerability Scoring System）指標

この CVE の CVSS 指標。

ベーススコア バージョン 深刻度 ベクトル 悪用しやすさ 影響 スコアの出典
5.5 3.1 MEDIUM
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H クリックして展開
攻撃ベクター (AV:L)
対象ホスト上でコードを実行できること、または別ユーザーの誤操作・悪意ある操作が前提になる。
攻撃の複雑さ (AC:L)
攻撃者が条件を満たせば、レース条件や珍しい構成に依存せずに再現しやすい。
必要な権限 (PR:L)
一般ユーザー権限があれば足り、管理者（root 相当）は不要。
ユーザーの関与 (UI:N)
メールのリンクを開く、マクロを有効にするなど、被害者の協力がなくても成立しうる。
スコープ (S:U)
影響は脆弱コンポーネントと同一のセキュリティ権限・信頼境界の内側に収まる。
機密性への影響 (C:N)
機微情報の漏えいは想定しにくい。
完全性への影響 (I:N)
改ざん・なりすましによる信頼毀損は軽微か、想定されない。
可用性への影響 (A:H)
長時間のサービス停止、データ損壊による復旧不能に近い状態など、利用者に著しい不便を与えうる。
 1.8 3.6 [email protected]

CVE-2026-31519 の弱点分類（列挙）

CVE-2026-31519 の GitHub Security Advisory

GHSA-p3jm-9f4h-xp4f · 深刻度： medium — In the Linux kernel, the following vulnerability has been resolved: btrfs: set...

CVE-2026-31519 の OS トラッカー

vendor priority summary link
debian not yet assigned CVE-2026-31519 not yet assigned priority: Debian including 2 source packages (linux, linux-6.1), 6 status rows across 5 suites (bookworm, bullseye, forky, sid, trixie): resolved 5, open 1. https://security-tracker.debian.org/tracker/CVE-2026-31519
redhat medium — https://access.redhat.com/security/cve/CVE-2026-31519
suse medium — https://www.suse.com/security/cve/CVE-2026-31519/
ubuntu medium CVE-2026-31519 medium priority: Ubuntu including 161 source packages (linux, linux-allwinner-5.19, …), 1449 status rows across 9 suites (bionic, focal, jammy, noble, questing, resolute, trusty, upstream, xenial): DNE 1048, ignored 173, needed 130, released 83, not-affected 11, needs-triage 4. https://ubuntu.com/security/CVE-2026-31519

CVE-2026-31519 の影響を受けるソフトウェア／構成

ベンダー 製品 バージョン 生の CPE
linux linux_kernel >= 2.6.32.19, < 2.6.33 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 2.6.33, < 6.1.168 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.2, < 6.6.131 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.7, < 6.12.80 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.13, < 6.18.21 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel >= 6.19, < 6.19.11 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
linux linux_kernel 7.0 cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:*
linux linux_kernel 7.0 cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:*
linux linux_kernel 7.0 cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:*

CVE-2026-31519 の参考情報

cvelogic Threat Intelligence