fkie_cve-2022-50571
Vulnerability from fkie_nvd
Published
2025-10-22 14:15
Modified
2025-10-22 21:12
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0 CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:btrfs_discard_update_discardable+0x98/0xb0 RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831e RBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010 R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80 FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0 Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock); We have a temporary free space ctl for loading the free space cache in order to avoid having allocations happening while we're loading the cache. When we hit an error we free it all up, however this also calls btrfs_discard_update_discardable, which requires block_group->free_space_ctl->tree_lock to be held. However this is our temporary ctl so this lock isn't held. Fix this by calling __btrfs_remove_free_space_cache_locked instead so that we only clean up the entries and do not mess with the discardable stats.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/819a61301275dcc573e3f520be3dc2c8531bee2d
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/8a1ae2781dee9fc21ca82db682d37bea4bd074ad
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: call __btrfs_remove_free_space_cache_locked on cache load failure\n\nNow that lockdep is staying enabled through our entire CI runs I started\nseeing the following stack in generic/475\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0\nCPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014\nWorkqueue: btrfs-cache btrfs_work_helper\nRIP: 0010:btrfs_discard_update_discardable+0x98/0xb0\nRSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001\nRDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831e\nRBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010\nR13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80\nFS:  0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0\nCall Trace:\n\n __btrfs_remove_free_space_cache+0x27/0x30\n load_free_space_cache+0xad2/0xaf0\n caching_thread+0x40b/0x650\n ? lock_release+0x137/0x2d0\n btrfs_work_helper+0xf2/0x3e0\n ? lock_is_held_type+0xe2/0x140\n process_one_work+0x271/0x590\n ? process_one_work+0x590/0x590\n worker_thread+0x52/0x3b0\n ? process_one_work+0x590/0x590\n kthread+0xf0/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n\nThis is the code\n\n        ctl = block_group-\u003efree_space_ctl;\n        discard_ctl = \u0026block_group-\u003efs_info-\u003ediscard_ctl;\n\n        lockdep_assert_held(\u0026ctl-\u003etree_lock);\n\nWe have a temporary free space ctl for loading the free space cache in\norder to avoid having allocations happening while we\u0027re loading the\ncache.  When we hit an error we free it all up, however this also calls\nbtrfs_discard_update_discardable, which requires\nblock_group-\u003efree_space_ctl-\u003etree_lock to be held.  However this is our\ntemporary ctl so this lock isn\u0027t held.  Fix this by calling\n__btrfs_remove_free_space_cache_locked instead so that we only clean up\nthe entries and do not mess with the discardable stats."
    }
  ],
  "id": "CVE-2022-50571",
  "lastModified": "2025-10-22T21:12:48.953",
  "metrics": {},
  "published": "2025-10-22T14:15:42.020",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/819a61301275dcc573e3f520be3dc2c8531bee2d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/8a1ae2781dee9fc21ca82db682d37bea4bd074ad"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




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.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • 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.