fkie_cve-2023-53538
Vulnerability from fkie_nvd
Published
2025-10-04 16:15
Modified
2025-10-06 14:56
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: insert tree mod log move in push_node_left There is a fairly unlikely race condition in tree mod log rewind that can result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0 This occurs when logical inode resolution takes a tree mod log sequence number, and then while backref walking hits a rewind on a busy node which has the following sequence of tree mod log operations (numbers filled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 When this sequence gets applied via btrfs_tree_mod_log_rewind, it allocates a fresh rewind eb, and first inserts the correct key info for the 533 elements, then overwrites the first 456 of them, then decrements the count by 456 via the add ops, then rewinds the move by doing a memmove from 456:988->0:532. We have never written anything past 532, ---truncated---
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: insert tree mod log move in push_node_left\n\nThere is a fairly unlikely race condition in tree mod log rewind that\ncan result in a kernel panic which has the following trace:\n\n  [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096\n  [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096\n  [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002\n  [530.618] #PF: supervisor read access in kernel mode\n  [530.629] #PF: error_code(0x0000) - not-present page\n  [530.641] PGD 0 P4D 0\n  [530.647] Oops: 0000 [#1] SMP\n  [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S         O  K   5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1\n  [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017\n  [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00\n  [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246\n  [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100\n  [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8\n  [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff\n  [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000\n  [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0\n  [530.848] FS:  00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000\n  [530.866] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0\n  [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  [530.928] Call Trace:\n  [530.934]  ? btrfs_printk+0x13b/0x18c\n  [530.943]  ? btrfs_bio_counter_inc_blocked+0x3d/0x130\n  [530.955]  btrfs_map_bio+0x75/0x330\n  [530.963]  ? kmem_cache_alloc+0x12a/0x2d0\n  [530.973]  ? btrfs_submit_metadata_bio+0x63/0x100\n  [530.984]  btrfs_submit_metadata_bio+0xa4/0x100\n  [530.995]  submit_extent_page+0x30f/0x360\n  [531.004]  read_extent_buffer_pages+0x49e/0x6d0\n  [531.015]  ? submit_extent_page+0x360/0x360\n  [531.025]  btree_read_extent_buffer_pages+0x5f/0x150\n  [531.037]  read_tree_block+0x37/0x60\n  [531.046]  read_block_for_search+0x18b/0x410\n  [531.056]  btrfs_search_old_slot+0x198/0x2f0\n  [531.066]  resolve_indirect_ref+0xfe/0x6f0\n  [531.076]  ? ulist_alloc+0x31/0x60\n  [531.084]  ? kmem_cache_alloc_trace+0x12e/0x2b0\n  [531.095]  find_parent_nodes+0x720/0x1830\n  [531.105]  ? ulist_alloc+0x10/0x60\n  [531.113]  iterate_extent_inodes+0xea/0x370\n  [531.123]  ? btrfs_previous_extent_item+0x8f/0x110\n  [531.134]  ? btrfs_search_path_in_tree+0x240/0x240\n  [531.146]  iterate_inodes_from_logical+0x98/0xd0\n  [531.157]  ? btrfs_search_path_in_tree+0x240/0x240\n  [531.168]  btrfs_ioctl_logical_to_ino+0xd9/0x180\n  [531.179]  btrfs_ioctl+0xe2/0x2eb0\n\nThis occurs when logical inode resolution takes a tree mod log sequence\nnumber, and then while backref walking hits a rewind on a busy node\nwhich has the following sequence of tree mod log operations (numbers\nfilled in from a specific example, but they are somewhat arbitrary)\n\n  REMOVE_WHILE_FREEING slot 532\n  REMOVE_WHILE_FREEING slot 531\n  REMOVE_WHILE_FREEING slot 530\n  ...\n  REMOVE_WHILE_FREEING slot 0\n  REMOVE slot 455\n  REMOVE slot 454\n  REMOVE slot 453\n  ...\n  REMOVE slot 0\n  ADD slot 455\n  ADD slot 454\n  ADD slot 453\n  ...\n  ADD slot 0\n  MOVE src slot 0 -\u003e dst slot 456 nritems 533\n  REMOVE slot 455\n  REMOVE slot 454\n  REMOVE slot 453\n  ...\n  REMOVE slot 0\n\nWhen this sequence gets applied via btrfs_tree_mod_log_rewind, it\nallocates a fresh rewind eb, and first inserts the correct key info for\nthe 533 elements, then overwrites the first 456 of them, then decrements\nthe count by 456 via the add ops, then rewinds the move by doing a\nmemmove from 456:988-\u003e0:532. We have never written anything past 532,\n---truncated---"
    }
  ],
  "id": "CVE-2023-53538",
  "lastModified": "2025-10-06T14:56:21.733",
  "metrics": {},
  "published": "2025-10-04T16:15:48.813",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/11f14402fe3437852cb44945b3b9f1bdb4032956"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5cead5422a0e3d13b0bcee986c0f5c4ebb94100b"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


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.
  • 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.


Loading…

Loading…