GHSA-MVC3-4Q88-Q347

Vulnerability from github – Published: 2025-10-14 21:30 – Updated: 2025-10-14 21:30
VLAI
Details

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

btrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone

btrfs_can_activate_zone() can be called with the device_list_mutex already held, which will lead to a deadlock:

insert_dev_extents() // Takes device_list_mutex -> insert_dev_extent()-> btrfs_insert_empty_item() -> btrfs_insert_empty_items()-> btrfs_search_slot() -> btrfs_cow_block()-> __btrfs_cow_block() -> btrfs_alloc_tree_block()-> btrfs_reserve_extent() -> find_free_extent()-> find_free_extent_update_loop() -> can_allocate_chunk()-> btrfs_can_activate_zone() // Takes device_list_mutex again

Instead of using the RCU on fs_devices->device_list we can use fs_devices->alloc_list, protected by the chunk_mutex to traverse the list of active devices.

We are in the chunk allocation thread. The newer chunk allocation happens from the devices in the fs_device->alloc_list protected by the chunk_mutex.

btrfs_create_chunk() lockdep_assert_held(&info->chunk_mutex); gather_device_info list_for_each_entry(device, &fs_devices->alloc_list, dev_alloc_list)

Also, a device that reappears after the mount won't join the alloc_list yet and, it will be in the dev_list, which we don't want to consider in the context of the chunk alloc.

[15.166572] WARNING: possible recursive locking detected [15.167117] 5.17.0-rc6-dennis #79 Not tainted [15.167487] -------------------------------------------- [15.167733] kworker/u8:3/146 is trying to acquire lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs] [15.167733] [15.167733] but task is already holding lock: [15.167733] ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.167733] [15.167733] other info that might help us debug this: [15.167733] Possible unsafe locking scenario: [15.167733] [15.171834] CPU0 [15.171834] ---- [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] lock(&fs_devs->device_list_mutex); [15.171834] [15.171834] *** DEADLOCK *** [15.171834] [15.171834] May be due to missing lock nesting notation [15.171834] [15.171834] 5 locks held by kworker/u8:3/146: [15.171834] #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.171834] #1: ffffc9000067be80 ((work_completion)(&fs_info->async_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0 [15.176244] #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs] [15.176244] #3: ffff888102962ee0 (&fs_devs->device_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs] [15.176244] #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs] [15.179641] [15.179641] stack backtrace: [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79 [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] [15.179641] Call Trace: [15.179641] [15.179641] dump_stack_lvl+0x45/0x59 [15.179641] __lock_acquire.cold+0x217/0x2b2 [15.179641] lock_acquire+0xbf/0x2b0 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] __mutex_lock+0x8e/0x970 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? lock_is_held_type+0xd7/0x130 [15.183838] ? find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] find_free_extent+0x15a/0x14f0 [btrfs] [15.183838] ? _raw_spin_unlock+0x24/0x40 [15.183838] ? btrfs_get_alloc_profile+0x106/0x230 [btrfs] [15.187601] btrfs_reserve_extent+0x131/0x260 [btrfs] [15. ---truncated---

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-49079"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-667"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-26T07:00:45Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: traverse devices under chunk_mutex in btrfs_can_activate_zone\n\nbtrfs_can_activate_zone() can be called with the device_list_mutex already\nheld, which will lead to a deadlock:\n\ninsert_dev_extents() // Takes device_list_mutex\n`-\u003e insert_dev_extent()\n `-\u003e btrfs_insert_empty_item()\n  `-\u003e btrfs_insert_empty_items()\n   `-\u003e btrfs_search_slot()\n    `-\u003e btrfs_cow_block()\n     `-\u003e __btrfs_cow_block()\n      `-\u003e btrfs_alloc_tree_block()\n       `-\u003e btrfs_reserve_extent()\n        `-\u003e find_free_extent()\n         `-\u003e find_free_extent_update_loop()\n          `-\u003e can_allocate_chunk()\n           `-\u003e btrfs_can_activate_zone() // Takes device_list_mutex again\n\nInstead of using the RCU on fs_devices-\u003edevice_list we\ncan use fs_devices-\u003ealloc_list, protected by the chunk_mutex to traverse\nthe list of active devices.\n\nWe are in the chunk allocation thread. The newer chunk allocation\nhappens from the devices in the fs_device-\u003ealloc_list protected by the\nchunk_mutex.\n\n  btrfs_create_chunk()\n    lockdep_assert_held(\u0026info-\u003echunk_mutex);\n    gather_device_info\n      list_for_each_entry(device, \u0026fs_devices-\u003ealloc_list, dev_alloc_list)\n\nAlso, a device that reappears after the mount won\u0027t join the alloc_list\nyet and, it will be in the dev_list, which we don\u0027t want to consider in\nthe context of the chunk alloc.\n\n  [15.166572] WARNING: possible recursive locking detected\n  [15.167117] 5.17.0-rc6-dennis #79 Not tainted\n  [15.167487] --------------------------------------------\n  [15.167733] kworker/u8:3/146 is trying to acquire lock:\n  [15.167733] ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: find_free_extent+0x15a/0x14f0 [btrfs]\n  [15.167733]\n  [15.167733] but task is already holding lock:\n  [15.167733] ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]\n  [15.167733]\n  [15.167733] other info that might help us debug this:\n  [15.167733]  Possible unsafe locking scenario:\n  [15.167733]\n  [15.171834]        CPU0\n  [15.171834]        ----\n  [15.171834]   lock(\u0026fs_devs-\u003edevice_list_mutex);\n  [15.171834]   lock(\u0026fs_devs-\u003edevice_list_mutex);\n  [15.171834]\n  [15.171834]  *** DEADLOCK ***\n  [15.171834]\n  [15.171834]  May be due to missing lock nesting notation\n  [15.171834]\n  [15.171834] 5 locks held by kworker/u8:3/146:\n  [15.171834]  #0: ffff888100050938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0\n  [15.171834]  #1: ffffc9000067be80 ((work_completion)(\u0026fs_info-\u003easync_data_reclaim_work)){+.+.}-{0:0}, at: process_one_work+0x1c3/0x5a0\n  [15.176244]  #2: ffff88810521e620 (sb_internal){.+.+}-{0:0}, at: flush_space+0x335/0x600 [btrfs]\n  [15.176244]  #3: ffff888102962ee0 (\u0026fs_devs-\u003edevice_list_mutex){+.+.}-{3:3}, at: btrfs_create_pending_block_groups+0x20a/0x560 [btrfs]\n  [15.176244]  #4: ffff8881152e4b78 (btrfs-dev-00){++++}-{3:3}, at: __btrfs_tree_lock+0x27/0x130 [btrfs]\n  [15.179641]\n  [15.179641] stack backtrace:\n  [15.179641] CPU: 1 PID: 146 Comm: kworker/u8:3 Not tainted 5.17.0-rc6-dennis #79\n  [15.179641] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014\n  [15.179641] Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]\n  [15.179641] Call Trace:\n  [15.179641]  \u003cTASK\u003e\n  [15.179641]  dump_stack_lvl+0x45/0x59\n  [15.179641]  __lock_acquire.cold+0x217/0x2b2\n  [15.179641]  lock_acquire+0xbf/0x2b0\n  [15.183838]  ? find_free_extent+0x15a/0x14f0 [btrfs]\n  [15.183838]  __mutex_lock+0x8e/0x970\n  [15.183838]  ? find_free_extent+0x15a/0x14f0 [btrfs]\n  [15.183838]  ? find_free_extent+0x15a/0x14f0 [btrfs]\n  [15.183838]  ? lock_is_held_type+0xd7/0x130\n  [15.183838]  ? find_free_extent+0x15a/0x14f0 [btrfs]\n  [15.183838]  find_free_extent+0x15a/0x14f0 [btrfs]\n  [15.183838]  ? _raw_spin_unlock+0x24/0x40\n  [15.183838]  ? btrfs_get_alloc_profile+0x106/0x230 [btrfs]\n  [15.187601]  btrfs_reserve_extent+0x131/0x260 [btrfs]\n  [15.\n---truncated---",
  "id": "GHSA-mvc3-4q88-q347",
  "modified": "2025-10-14T21:30:25Z",
  "published": "2025-10-14T21:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49079"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/09e65ae515af2b24d6dc23af21719a3b41de83e5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b9e66762aa0cda2a9c2d5542d64e04dac528fa6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/142f822bd945a7be442a2916ec6167cc102c4183"
    }
  ],
  "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.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…