Skip to content
Heist/ feed
Back to feed
UnratedFix available

btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create

Type: advisorySources: OSV

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 drop

Products
Kernel
Affected versions
Not specified
Fixed versions
6.1.168, 6.12.80, 6.18.21, 6.19.11, 6.6.131
CVEs
CVE-2026-31519
Confirmed fixed CVEs
Not specified
Updated in this feed
7 Nov 2026, 14:30 UTC · Revision 1

Source evidence

btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create

core-osv · Original source

Published 22 Apr 2026, 13:54 UTC

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 drop

osv:CVE-2026-31519

Kernel

Fixed versions: 6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11

Complete source record
{
  "id": "fd877f7184bef0f9f13c83f6d0ff9f111c127b26c0ea9817677d4a47847272aa",
  "url": "https://osv.dev/vulnerability/CVE-2026-31519",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create",
    "summary": "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 drop",
    "evidence": "osv:CVE-2026-31519",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.1.168",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.131",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.80",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.21",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.19.11",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2026-31519",
      "aliases": [
        "CVE-2026-31519"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "c71bf099abddf3e0fdc27f251ba76fca1461d49a"
                },
                {
                  "fixed": "d43da8de0ed376abafbad8a245a1835e8f66cb0f"
                },
                {
                  "fixed": "c57276ced3c3207f42182dfa2f0d8e860357e111"
                },
                {
                  "fixed": "a41a9b8d19a98b45591528c6e54d31cc66271d1e"
                },
                {
                  "fixed": "2ec578e6452138ab76f6c9a9c18711fcd197649f"
                },
                {
                  "fixed": "696683f214495db3cdacab9a713efaaced8660f8"
                },
                {
                  "fixed": "5131fa077f9bb386a1b901bf5b247041f0ec8f80"
                }
              ]
            },
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "2.6.32.19"
                },
                {
                  "fixed": "2.6.33"
                }
              ]
            },
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "c4ba0bd9db5e8fd2664be0fd4ec01335fe3268eb"
                }
              ]
            }
          ],
          "versions": [
            "v2.6.32.71",
            "v2.6.32.70",
            "v2.6.32.69",
            "v2.6.32.68",
            "v2.6.32.67",
            "v2.6.32.66",
            "v2.6.32.65",
            "v2.6.32.64",
            "v2.6.32.63",
            "v2.6.32.62",
            "v2.6.32.61",
            "v2.6.32.60",
            "v2.6.32.59",
            "v2.6.32.58",
            "v2.6.32.57",
            "v2.6.32.56",
            "v2.6.32.55",
            "v2.6.32.54",
            "v2.6.32.53",
            "v2.6.32.52",
            "v2.6.32.51",
            "v2.6.32.50",
            "v2.6.32.49",
            "v2.6.32.48",
            "v2.6.32.47",
            "v2.6.32.46",
            "v2.6.32.45",
            "v2.6.32.44",
            "v2.6.32.43",
            "v2.6.32.42",
            "v2.6.32.41",
            "v2.6.32.40",
            "v2.6.32.39",
            "v2.6.32.38",
            "v2.6.32.37",
            "v2.6.32.36",
            "v2.6.32.35",
            "v2.6.32.34",
            "v2.6.32.33",
            "v2.6.32.32",
            "v2.6.32.31",
            "v2.6.32.30",
            "v2.6.32.29",
            "v2.6.32.28",
            "v2.6.32.27",
            "v2.6.32.26",
            "v2.6.32.25",
            "v2.6.32.24",
            "v2.6.32.23",
            "v2.6.32.22",
            "v2.6.32.21",
            "v2.6.32.20",
            "v2.6.32.19"
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31519.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "2.6.33"
                },
                {
                  "fixed": "6.1.168"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.131"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.80"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.21"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "6.19.11"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-31519.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:51.013143814Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/2ec578e6452138ab76f6c9a9c18711fcd197649f",
        "https://git.kernel.org/stable/c/5131fa077f9bb386a1b901bf5b247041f0ec8f80",
        "https://git.kernel.org/stable/c/696683f214495db3cdacab9a713efaaced8660f8",
        "https://git.kernel.org/stable/c/a41a9b8d19a98b45591528c6e54d31cc66271d1e",
        "https://git.kernel.org/stable/c/c57276ced3c3207f42182dfa2f0d8e860357e111",
        "https://git.kernel.org/stable/c/d43da8de0ed376abafbad8a245a1835e8f66cb0f",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31519.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-31519",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/31xxx/CVE-2026-31519.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-31519",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 519635,
  "published_at": "2026-04-22T13:54:34.86+00:00"
}