https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 15:36:25 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-10185 bdu:2026-10185 https://cve.radiocsirt.org/vuln/bdu:2026-10185 https://cve.radiocsirt.org/vuln/bell-cve-2023-53187 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://cve.radiocsirt.org/vuln/bell-cve-2023-53187 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895 certfr-2025-avi-0895 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895 https://cve.radiocsirt.org/vuln/euvd-2026-345153 EUVD-2026-345153 https://cve.radiocsirt.org/vuln/euvd-2026-345153 https://cve.radiocsirt.org/vuln/fkie_cve-2023-53187 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix use-after-free of new block group that became unused</p> <p>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:</p> <p>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&#39;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;</p> <p>2) We don&#39;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&#39;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 lead…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix use-after-free of new block group that became unused</p> <p>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:</p> <p>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&#39;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;</p> <p>2) We don&#39;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&#39;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 lead…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-53187 https://cve.radiocsirt.org/vuln/ghsa-4xcf-q92v-qp8c <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix use-after-free of new block group that became unused</p> <p>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:</p> <p>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&#39;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;</p> <p>2) We don&#39;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&#39;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 lead…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix use-after-free of new block group that became unused</p> <p>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:</p> <p>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&#39;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;</p> <p>2) We don&#39;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&#39;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 lead…</p> https://cve.radiocsirt.org/vuln/ghsa-4xcf-q92v-qp8c https://cve.radiocsirt.org/vuln/msrc_cve-2023-53187 msrc_CVE-2023-53187 https://cve.radiocsirt.org/vuln/msrc_cve-2023-53187 https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:03600-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53187 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 116 more</p> <p>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&#39;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&#39;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&#39;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…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 116 more</p> <p>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&#39;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&#39;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&#39;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…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53187 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053