Skip to content
Heist/ feed
Back to feed
UnratedFix available

btrfs: do not assert we found block group item when creating free space tree

Type: advisorySources: OSV

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/fre

Products
Kernel
Affected versions
Not specified
Fixed versions
6.1.158, 6.12.55, 6.17.5, 6.6.114
CVEs
CVE-2025-40100
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 08:27 UTC · Revision 1

Source evidence

btrfs: do not assert we found block group item when creating free space tree

core-osv · Original source

Published 30 Oct 2025, 09:48 UTC

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/fre

osv:CVE-2025-40100

Kernel

Fixed versions: 6.1.158, 6.6.114, 6.12.55, 6.17.5

Complete source record
{
  "id": "a9bd1992052423896f97a73704a98464d2579c197fb05c6e2db6d64cf58e8a13",
  "url": "https://osv.dev/vulnerability/CVE-2025-40100",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "btrfs: do not assert we found block group item when creating free space tree",
    "summary": "In the Linux kernel, the following vulnerability has been resolved: btrfs: do not assert we found block group item when creating free space tree Currently, when building a free space tree at populate_free_space_tree(), if we are not using the block group tree feature, we always expect to find block group items (either extent items or a block group item with key type BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with btrfs_search_slot_for_read(), so we assert that we found an item. However this expectation is wrong since we can have a new block group created in the current transaction which is still empty and for which we still have not added the block group's item to the extent tree, in which case we do not have any items in the extent tree associated to the block group. The insertion of a new block group's block group item in the extent tree happens at btrfs_create_pending_block_groups() when it calls the helper insert_block_group_item(). This typically is done when a transaction handle is released, committed or when running delayed refs (either as part of a transaction commit or when serving tickets for space reservation if we are low on free space). So remove the assertion at populate_free_space_tree() even when the block group tree feature is not enabled and update the comment to mention this case. Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/fre",
    "evidence": "osv:CVE-2025-40100",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.1.158",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.6.114",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.12.55",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.17.5",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "unknown",
    "structured": {
      "id": "CVE-2025-40100",
      "aliases": [
        "CVE-2025-40100"
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "a5ed91828518ab076209266c2bc510adabd078df"
                },
                {
                  "fixed": "4f4b9ca73f84130d9fbb0fc02306ce94ce8bdbe6"
                },
                {
                  "fixed": "289498da343b05c886f19b4269429606f86dd17b"
                },
                {
                  "fixed": "3fdcfd91b93f930d87843156c7c8cc5fbcf9b144"
                },
                {
                  "fixed": "eb145463f22d7d32d426b29fe9810de9e792b6ba"
                },
                {
                  "fixed": "a5a51bf4e9b7354ce7cd697e610d72c1b33fd949"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-40100.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "4.5.0"
                },
                {
                  "fixed": "6.1.158"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.2.0"
                },
                {
                  "fixed": "6.6.114"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.7.0"
                },
                {
                  "fixed": "6.12.55"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.17.5"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-40100.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:33.806319068Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/289498da343b05c886f19b4269429606f86dd17b",
        "https://git.kernel.org/stable/c/3fdcfd91b93f930d87843156c7c8cc5fbcf9b144",
        "https://git.kernel.org/stable/c/4f4b9ca73f84130d9fbb0fc02306ce94ce8bdbe6",
        "https://git.kernel.org/stable/c/a5a51bf4e9b7354ce7cd697e610d72c1b33fd949",
        "https://git.kernel.org/stable/c/eb145463f22d7d32d426b29fe9810de9e792b6ba",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/40xxx/CVE-2025-40100.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2025-40100",
        "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/2025/40xxx/CVE-2025-40100.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2025-40100",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": null
  },
  "source_id": "core-osv",
  "document_id": 501125,
  "published_at": "2025-10-30T09:48:06.521+00:00"
}