ghsa-758w-9j7r-h7p8
Vulnerability from github
Published
2024-08-21 09:31
Modified
2024-09-13 15:31
Details

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

btrfs: qgroup: do not warn on record without old_roots populated

[BUG] There are some reports from the mailing list that since v6.1 kernel, the WARN_ON() inside btrfs_qgroup_account_extent() gets triggered during rescan:

WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs] CPU: 3 PID: 6424 Comm: snapperd Tainted: P OE 6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7 RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs] Call Trace: btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6] ? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6] btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6] btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6] ? __rseq_handle_notify_resume+0xa9/0x4a0 ? mntput_no_expire+0x4a/0x240 ? __seccomp_filter+0x319/0x4d0 __x64_sys_ioctl+0x90/0xd0 do_syscall_64+0x5b/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd9b790d9bf

[CAUSE] Since commit e15e9f43c7ca ("btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting"), if our qgroup is already in inconsistent state, we will no longer do the time-consuming backref walk.

This can leave some qgroup records without a valid old_roots ulist. Normally this is fine, as btrfs_qgroup_account_extents() would also skip those records if we have NO_ACCOUNTING flag set.

But there is a small window, if we have NO_ACCOUNTING flag set, and inserted some qgroup_record without a old_roots ulist, but then the user triggered a qgroup rescan.

During btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then commit current transaction.

And since we have a qgroup_record with old_roots = NULL, we trigger the WARN_ON() during btrfs_qgroup_account_extents().

[FIX] Unfortunately due to the introduction of NO_ACCOUNTING flag, the assumption that every qgroup_record would have its old_roots populated is no longer correct.

Fix the false alerts and drop the WARN_ON().

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2023-52897"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T07:15:06Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: qgroup: do not warn on record without old_roots populated\n\n[BUG]\nThere are some reports from the mailing list that since v6.1 kernel, the\nWARN_ON() inside btrfs_qgroup_account_extent() gets triggered during\nrescan:\n\n  WARNING: CPU: 3 PID: 6424 at fs/btrfs/qgroup.c:2756 btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]\n  CPU: 3 PID: 6424 Comm: snapperd Tainted: P           OE      6.1.2-1-default #1 openSUSE Tumbleweed 05c7a1b1b61d5627475528f71f50444637b5aad7\n  RIP: 0010:btrfs_qgroup_account_extents+0x1ae/0x260 [btrfs]\n  Call Trace:\n   \u003cTASK\u003e\n  btrfs_commit_transaction+0x30c/0xb40 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n   ? start_transaction+0xc3/0x5b0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n  btrfs_qgroup_rescan+0x42/0xc0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n   btrfs_ioctl+0x1ab9/0x25c0 [btrfs c39c9c546c241c593f03bd6d5f39ea1b676250f6]\n   ? __rseq_handle_notify_resume+0xa9/0x4a0\n   ? mntput_no_expire+0x4a/0x240\n   ? __seccomp_filter+0x319/0x4d0\n   __x64_sys_ioctl+0x90/0xd0\n   do_syscall_64+0x5b/0x80\n   ? syscall_exit_to_user_mode+0x17/0x40\n   ? do_syscall_64+0x67/0x80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  RIP: 0033:0x7fd9b790d9bf\n   \u003c/TASK\u003e\n\n[CAUSE]\nSince commit e15e9f43c7ca (\"btrfs: introduce\nBTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting\"), if\nour qgroup is already in inconsistent state, we will no longer do the\ntime-consuming backref walk.\n\nThis can leave some qgroup records without a valid old_roots ulist.\nNormally this is fine, as btrfs_qgroup_account_extents() would also skip\nthose records if we have NO_ACCOUNTING flag set.\n\nBut there is a small window, if we have NO_ACCOUNTING flag set, and\ninserted some qgroup_record without a old_roots ulist, but then the user\ntriggered a qgroup rescan.\n\nDuring btrfs_qgroup_rescan(), we firstly clear NO_ACCOUNTING flag, then\ncommit current transaction.\n\nAnd since we have a qgroup_record with old_roots = NULL, we trigger the\nWARN_ON() during btrfs_qgroup_account_extents().\n\n[FIX]\nUnfortunately due to the introduction of NO_ACCOUNTING flag, the\nassumption that every qgroup_record would have its old_roots populated\nis no longer correct.\n\nFix the false alerts and drop the WARN_ON().",
  "id": "GHSA-758w-9j7r-h7p8",
  "modified": "2024-09-13T15:31:31Z",
  "published": "2024-08-21T09:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52897"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/75181406b4eafacc531ff2ee5fb032bd93317e2b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bb2c2e62539f2b63c5e0beb51501d328260c7595"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/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.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.