GHSA-VMMW-67M5-V7RP
Vulnerability from github – Published: 2025-12-24 15:30 – Updated: 2025-12-24 15:30In the Linux kernel, the following vulnerability has been resolved:
btrfs: zoned: skip splitting and logical rewriting on pre-alloc write
When doing a relocation, there is a chance that at the time of btrfs_reloc_clone_csums(), there is no checksum for the corresponding region.
In this case, btrfs_finish_ordered_zoned()'s sum points to an invalid item and so ordered_extent's logical is set to some invalid value. Then, btrfs_lookup_block_group() in btrfs_zone_finish_endio() failed to find a block group and will hit an assert or a null pointer dereference as following.
This can be reprodcued by running btrfs/028 several times (e.g, 4 to 16 times) with a null_blk setup. The device's zone size and capacity is set to 32 MB and the storage size is set to 5 GB on my setup.
KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]
CPU: 6 PID: 3105720 Comm: kworker/u16:13 Tainted: G W 6.5.0-rc6-kts+ #1
Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015
Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]
Code: 41 54 49 89 fc 55 48 89 f5 53 e8 57 7d fc ff 48 8d b8 88 00 00 00 48 89 c3 48 b8 00 00 00 00 00
> 3c 02 00 0f 85 02 01 00 00 f6 83 88 00 00 00 01 0f 84 a8 00 00
RSP: 0018:ffff88833cf87b08 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088
RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed102877b827
R10: ffff888143bdc13b R11: ffff888125b1cbc0 R12: ffff888143bdc000
R13: 0000000000007000 R14: ffff888125b1cba8 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88881e500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f3ed85223d5 CR3: 00000001519b4005 CR4: 00000000001706e0
Call Trace:
<TASK>
? die_addr+0x3c/0xa0
? exc_general_protection+0x148/0x220
? asm_exc_general_protection+0x22/0x30
? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]
? btrfs_zone_finish_endio.part.0+0x19/0x160 [btrfs]
btrfs_finish_one_ordered+0x7b8/0x1de0 [btrfs]
? rcu_is_watching+0x11/0xb0
? lock_release+0x47a/0x620
? btrfs_finish_ordered_zoned+0x59b/0x800 [btrfs]
? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]
? btrfs_finish_ordered_zoned+0x358/0x800 [btrfs]
? __smp_call_single_queue+0x124/0x350
? rcu_is_watching+0x11/0xb0
btrfs_work_helper+0x19f/0xc60 [btrfs]
? __pfx_try_to_wake_up+0x10/0x10
? _raw_spin_unlock_irq+0x24/0x50
? rcu_is_watching+0x11/0xb0
process_one_work+0x8c1/0x1430
? __pfx_lock_acquire+0x10/0x10
? __pfx_process_one_work+0x10/0x10
? __pfx_do_raw_spin_lock+0x10/0x10
? _raw_spin_lock_irq+0x52/0x60
worker_thread+0x100/0x12c0
? __kthread_parkme+0xc1/0x1f0
? __pfx_worker_thread+0x10/0x10
kthread+0x2ea/0x3c0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x30/0x70
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
</TASK>
On the zoned mode, writing to pre-allocated region means data relocation write. Such write always uses WRITE command so there is no need of splitting and rewriting logical address. Thus, we can just skip the function for the case.
{
"affected": [],
"aliases": [
"CVE-2023-54080"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-24T13:16:09Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: skip splitting and logical rewriting on pre-alloc write\n\nWhen doing a relocation, there is a chance that at the time of\nbtrfs_reloc_clone_csums(), there is no checksum for the corresponding\nregion.\n\nIn this case, btrfs_finish_ordered_zoned()\u0027s sum points to an invalid item\nand so ordered_extent\u0027s logical is set to some invalid value. Then,\nbtrfs_lookup_block_group() in btrfs_zone_finish_endio() failed to find a\nblock group and will hit an assert or a null pointer dereference as\nfollowing.\n\nThis can be reprodcued by running btrfs/028 several times (e.g, 4 to 16\ntimes) with a null_blk setup. The device\u0027s zone size and capacity is set to\n32 MB and the storage size is set to 5 GB on my setup.\n\n KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]\n CPU: 6 PID: 3105720 Comm: kworker/u16:13 Tainted: G W 6.5.0-rc6-kts+ #1\n Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015\n Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]\n RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n Code: 41 54 49 89 fc 55 48 89 f5 53 e8 57 7d fc ff 48 8d b8 88 00 00 00 48 89 c3 48 b8 00 00 00 00 00\n \u003e 3c 02 00 0f 85 02 01 00 00 f6 83 88 00 00 00 01 0f 84 a8 00 00\n RSP: 0018:ffff88833cf87b08 EFLAGS: 00010206\n RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088\n RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed102877b827\n R10: ffff888143bdc13b R11: ffff888125b1cbc0 R12: ffff888143bdc000\n R13: 0000000000007000 R14: ffff888125b1cba8 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff88881e500000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f3ed85223d5 CR3: 00000001519b4005 CR4: 00000000001706e0\n Call Trace:\n \u003cTASK\u003e\n ? die_addr+0x3c/0xa0\n ? exc_general_protection+0x148/0x220\n ? asm_exc_general_protection+0x22/0x30\n ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs]\n ? btrfs_zone_finish_endio.part.0+0x19/0x160 [btrfs]\n btrfs_finish_one_ordered+0x7b8/0x1de0 [btrfs]\n ? rcu_is_watching+0x11/0xb0\n ? lock_release+0x47a/0x620\n ? btrfs_finish_ordered_zoned+0x59b/0x800 [btrfs]\n ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs]\n ? btrfs_finish_ordered_zoned+0x358/0x800 [btrfs]\n ? __smp_call_single_queue+0x124/0x350\n ? rcu_is_watching+0x11/0xb0\n btrfs_work_helper+0x19f/0xc60 [btrfs]\n ? __pfx_try_to_wake_up+0x10/0x10\n ? _raw_spin_unlock_irq+0x24/0x50\n ? rcu_is_watching+0x11/0xb0\n process_one_work+0x8c1/0x1430\n ? __pfx_lock_acquire+0x10/0x10\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? _raw_spin_lock_irq+0x52/0x60\n worker_thread+0x100/0x12c0\n ? __kthread_parkme+0xc1/0x1f0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2ea/0x3c0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n \u003c/TASK\u003e\n\nOn the zoned mode, writing to pre-allocated region means data relocation\nwrite. Such write always uses WRITE command so there is no need of splitting\nand rewriting logical address. Thus, we can just skip the function for the\ncase.",
"id": "GHSA-vmmw-67m5-v7rp",
"modified": "2025-12-24T15:30:37Z",
"published": "2025-12-24T15:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54080"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c02d35d89b317994bd713ba82e160c5e7f22d9c8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d3cfa44164688a076e8b476cafb5df87d07cfa63"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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
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…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.