GHSA-7R7H-HW2C-CP7Q

Vulnerability from github – Published: 2025-07-09 12:31 – Updated: 2025-12-18 18:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

btrfs: handle csum tree error with rescue=ibadroots correctly

[BUG] There is syzbot based reproducer that can crash the kernel, with the following call trace: (With some debug output added)

DEBUG: rescue=ibadroots parsed BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010) BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8 BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm BTRFS info (device loop0): using free-space-tree BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0 DEBUG: read tree root path failed for tree csum, ret=-5 BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0 BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0 process 'repro' launched './file2' with NULL argv: empty string added DEBUG: no csum root, idatacsums=0 ibadroots=134217728 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G OE 6.15.0-custom+ #249 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs] Call Trace: btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs] btrfs_submit_bbio+0x43e/0x1a80 [btrfs] submit_one_bio+0xde/0x160 [btrfs] btrfs_readahead+0x498/0x6a0 [btrfs] read_pages+0x1c3/0xb20 page_cache_ra_order+0x4b5/0xc20 filemap_get_pages+0x2d3/0x19e0 filemap_read+0x314/0xde0 __kernel_read+0x35b/0x900 bprm_execve+0x62e/0x1140 do_execveat_common.isra.0+0x3fc/0x520 __x64_sys_execveat+0xdc/0x130 do_syscall_64+0x54/0x1d0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---

[CAUSE] Firstly the fs has a corrupted csum tree root, thus to mount the fs we have to go "ro,rescue=ibadroots" mount option.

Normally with that mount option, a bad csum tree root should set BTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will ignore csum search.

But in this particular case, we have the following call trace that caused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS:

load_global_roots_objectid():

    ret = btrfs_search_slot();
    /* Succeeded */
    btrfs_item_key_to_cpu()
    found = true;
    /* We found the root item for csum tree. */
    root = read_tree_root_path();
    if (IS_ERR(root)) {
        if (!btrfs_test_opt(fs_info, IGNOREBADROOTS))
        /*
         * Since we have rescue=ibadroots mount option,
         * @ret is still 0.
         */
        break;
if (!found || ret) {
    /* @found is true, @ret is 0, error handling for csum
     * tree is skipped.
     */
}

This means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if the csum tree is corrupted, which results unexpected later csum lookup.

[FIX] If read_tree_root_path() failed, always populate @ret to the error number.

As at the end of the function, we need @ret to determine if we need to do the extra error handling for csum tree.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-38260"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-09T11:15:28Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: handle csum tree error with rescue=ibadroots correctly\n\n[BUG]\nThere is syzbot based reproducer that can crash the kernel, with the\nfollowing call trace: (With some debug output added)\n\n DEBUG: rescue=ibadroots parsed\n BTRFS: device fsid 14d642db-7b15-43e4-81e6-4b8fac6a25f8 devid 1 transid 8 /dev/loop0 (7:0) scanned by repro (1010)\n BTRFS info (device loop0): first mount of filesystem 14d642db-7b15-43e4-81e6-4b8fac6a25f8\n BTRFS info (device loop0): using blake2b (blake2b-256-generic) checksum algorithm\n BTRFS info (device loop0): using free-space-tree\n BTRFS warning (device loop0): checksum verify failed on logical 5312512 mirror 1 wanted 0xb043382657aede36608fd3386d6b001692ff406164733d94e2d9a180412c6003 found 0x810ceb2bacb7f0f9eb2bf3b2b15c02af867cb35ad450898169f3b1f0bd818651 level 0\n DEBUG: read tree root path failed for tree csum, ret=-5\n BTRFS warning (device loop0): checksum verify failed on logical 5328896 mirror 1 wanted 0x51be4e8b303da58e6340226815b70e3a93592dac3f30dd510c7517454de8567a found 0x51be4e8b303da58e634022a315b70e3a93592dac3f30dd510c7517454de8567a level 0\n BTRFS warning (device loop0): checksum verify failed on logical 5292032 mirror 1 wanted 0x1924ccd683be9efc2fa98582ef58760e3848e9043db8649ee382681e220cdee4 found 0x0cb6184f6e8799d9f8cb335dccd1d1832da1071d12290dab3b85b587ecacca6e level 0\n process \u0027repro\u0027 launched \u0027./file2\u0027 with NULL argv: empty string added\n DEBUG: no csum root, idatacsums=0 ibadroots=134217728\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] SMP KASAN NOPTI\n KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]\n CPU: 5 UID: 0 PID: 1010 Comm: repro Tainted: G           OE       6.15.0-custom+ #249 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:btrfs_lookup_csum+0x93/0x3d0 [btrfs]\n Call Trace:\n  \u003cTASK\u003e\n  btrfs_lookup_bio_sums+0x47a/0xdf0 [btrfs]\n  btrfs_submit_bbio+0x43e/0x1a80 [btrfs]\n  submit_one_bio+0xde/0x160 [btrfs]\n  btrfs_readahead+0x498/0x6a0 [btrfs]\n  read_pages+0x1c3/0xb20\n  page_cache_ra_order+0x4b5/0xc20\n  filemap_get_pages+0x2d3/0x19e0\n  filemap_read+0x314/0xde0\n  __kernel_read+0x35b/0x900\n  bprm_execve+0x62e/0x1140\n  do_execveat_common.isra.0+0x3fc/0x520\n  __x64_sys_execveat+0xdc/0x130\n  do_syscall_64+0x54/0x1d0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ---[ end trace 0000000000000000 ]---\n\n[CAUSE]\nFirstly the fs has a corrupted csum tree root, thus to mount the fs we\nhave to go \"ro,rescue=ibadroots\" mount option.\n\nNormally with that mount option, a bad csum tree root should set\nBTRFS_FS_STATE_NO_DATA_CSUMS flag, so that any future data read will\nignore csum search.\n\nBut in this particular case, we have the following call trace that\ncaused NULL csum root, but not setting BTRFS_FS_STATE_NO_DATA_CSUMS:\n\nload_global_roots_objectid():\n\n\t\tret = btrfs_search_slot();\n\t\t/* Succeeded */\n\t\tbtrfs_item_key_to_cpu()\n\t\tfound = true;\n\t\t/* We found the root item for csum tree. */\n\t\troot = read_tree_root_path();\n\t\tif (IS_ERR(root)) {\n\t\t\tif (!btrfs_test_opt(fs_info, IGNOREBADROOTS))\n\t\t\t/*\n\t\t\t * Since we have rescue=ibadroots mount option,\n\t\t\t * @ret is still 0.\n\t\t\t */\n\t\t\tbreak;\n\tif (!found || ret) {\n\t\t/* @found is true, @ret is 0, error handling for csum\n\t\t * tree is skipped.\n\t\t */\n\t}\n\nThis means we completely skipped to set BTRFS_FS_STATE_NO_DATA_CSUMS if\nthe csum tree is corrupted, which results unexpected later csum lookup.\n\n[FIX]\nIf read_tree_root_path() failed, always populate @ret to the error\nnumber.\n\nAs at the end of the function, we need @ret to determine if we need to\ndo the extra error handling for csum tree.",
  "id": "GHSA-7r7h-hw2c-cp7q",
  "modified": "2025-12-18T18:30:28Z",
  "published": "2025-07-09T12:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38260"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/3f5c4a996f8f4fecd24a3eb344a307c50af895c2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/547e836661554dcfa15c212a3821664e85b4191a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bbe9231fe611a54a447962494472f604419bad59"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8ce11903211542a61f05c02caedd2edfb4256b8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/fc97a116dc4929905538bc0bd3af7faa51192957"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.