CVE-2023-53187
published 2025-09-15CVE-2023-53187: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of new block group that became unused If a task creates a new…
PriorityP339high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.15%
4.5th percentile
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of new block group that became unused
If a task creates a new block group and that block group becomes unused
before we finish its creation, at btrfs_create_pending_block_groups(),
then when btrfs_mark_bg_unused() is called against the block group, we
assume that the block group is currently in the list of block groups to
reclaim, and we move it out of the list of new block groups and into the
list of unused block groups. This has two consequences:
1) We move it out of the list of new block groups associated to the
current transaction. So the block group creation is not finished and
if we attempt to delete the bg because it's unused, we will not find
the block group item in the extent tree (or the new block group tree),
its device extent items in the device tree etc, resulting in the
deletion to fail due to the missing items;
2) We don't increment the reference count on the block group when we
move it to the list of unused block groups, because we assumed the
block group was on the list of block groups to reclaim, and in that
case it already has the correct reference count. However the block
group was on the list of new block groups, in which case no extra
reference was taken because it's local to the current task. This
later results in doing an extra reference count decrement when
removing the block group from the unused list, eventually leading the
reference count to 0.
This second case was caught when running generic/297 from fstests, which
produced the following assertion failure and stack trace:
[589.559] assertion failed: refcount_read(&block_group->refs) == 1, in fs/btrfs/block-group.c:4299
[589.559] ------------[ cut here ]------------
[589.559] kernel BUG at fs/btrfs/block-group.c:4299!
[589.560] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[589.560] CPU: 8 PID: 2819134 Comm: umount Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1
[589.560] Hardware name: QEMU Standard
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.52-1 (bookworm) | linux 6.1.52-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 01eca70ef8cf499d0cb6d1bbd691558e7792cf17 < 6297644db23f77c02ae7961cc542d162629ae2c4 | 6297644db23f77c02ae7961cc542d162629ae2c4 |
| linux | linux | >= 5.15.128 < 5.16 | 5.16 |
| linux | linux | >= 5d19abcffd8404078dfa7d7118cec357b5e7bc58 < 7569c4294ba6ff9f194635b14876198f8a687c4a | 7569c4294ba6ff9f194635b14876198f8a687c4a |
| linux | linux | >= a9f189716cf15913c453299d72f69c51a9b0f86b < 0657b20c5a76c938612f8409735a8830d257866e | 0657b20c5a76c938612f8409735a8830d257866e |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.52-1 | 6.1.52-1 |
| linux | linux_kernel | >= 0 < 6.4.13-1 | 6.4.13-1 |
| linux | linux_kernel | >= 0 < 6.4.13-1 | 6.4.13-1 |
| linux | linux_kernel | >= 5.15.128 < 5.16 | 5.16 |
| msrc | cbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0 | — | — |
| msrc | cbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0 | — | — |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_msrc7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: btrfs: fix use-after-free of new block group that became unused
vendor_redhat·2025-09-15·CVSS 7.8
CVE-2023-53187 [HIGH] kernel: btrfs: fix use-after-free of new block group that became unused
kernel: btrfs: fix use-after-free of new block group that became unused
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of new block group that became unused
If a task creates a new block group and that block group becomes unused
before we finish its creation, at btrfs_create_pending_block_groups(),
then when btrfs_mark_bg_unused() is called against the block group, we
assume that the block group is currently in the list of block groups to
reclaim, and we move it out of the list of new block groups and into the
list of unused block groups. This has two consequences:
1) We move it out of the list of new block groups associated to the
current transaction. So the block group creation is not finished and
if we attempt to delete the bg because it's
Microsoft
btrfs: fix use-after-free of new block group that became unused
vendor_msrc·2025-09-09·CVSS 7.8
CVE-2023-53187 [HIGH] CWE-416 btrfs: fix use-after-free of new block group that became unused
btrfs: fix use-after-free of new block group that became unused
Mariner: Mariner
Linux: Linux
Customer Action Required: Yes
Debian
CVE-2023-53187: linux - In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ...
vendor_debian·2023·CVSS 7.8
CVE-2023-53187 [HIGH] CVE-2023-53187: linux - In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ...
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of new block group that became unused If a task creates a new block group and that block group becomes unused before we finish its creation, at btrfs_create_pending_block_groups(), then when btrfs_mark_bg_unused() is called against the block group, we assume that the block group is currently in the list of block groups to reclaim, and we move it out of the list of new block groups and into the list of unused block groups. This has two consequences: 1) We move it out of the list of new block groups associated to the current transaction. So the block group creation is not finished and if we attempt to delete the bg because it's unused, we will not find the block group item in the extent tree (or the
GHSA
GHSA-4xcf-q92v-qp8c: In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of new block group that became unused
If a task create
ghsa_unreviewed·2025-09-15
CVE-2023-53187 [HIGH] CWE-416 GHSA-4xcf-q92v-qp8c: In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of new block group that became unused
If a task create
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free of new block group that became unused
If a task creates a new block group and that block group becomes unused
before we finish its creation, at btrfs_create_pending_block_groups(),
then when btrfs_mark_bg_unused() is called against the block group, we
assume that the block group is currently in the list of block groups to
reclaim, and we move it out of the list of new block groups and into the
list of unused block groups. This has two consequences:
1) We move it out of the list of new block groups associated to the
current transaction. So the block group creation is not finished and
if we attempt to delete the bg because it's unused, we will not find
the block group item in the extent tree (or
OSV
CVE-2023-53187: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of new block group that became unused If a task creates
osv·2025-09-15·CVSS 7.8
CVE-2023-53187 [HIGH] CVE-2023-53187: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of new block group that became unused If a task creates
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of new block group that became unused If a task creates a new block group and that block group becomes unused before we finish its creation, at btrfs_create_pending_block_groups(), then when btrfs_mark_bg_unused() is called against the block group, we assume that the block group is currently in the list of block groups to reclaim, and we move it out of the list of new block groups and into the list of unused block groups. This has two consequences: 1) We move it out of the list of new block groups associated to the current transaction. So the block group creation is not finished and if we attempt to delete the bg because it's unused, we will not find the block group item in the extent tree (or the
No detection rules found.
No public exploits indexed.
2025-09-15
Published