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

Affected: Linux

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 beha…

Most recent entries from all

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