<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 08:06:50 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-45934</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-45934</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-45934</guid>
    </item>
    <item>
      <title>EUVD-2026-321842</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-321842</link>
      <description>EUVD-2026-321842</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-321842</guid>
    </item>
    <item>
      <title>fkie_cve-2026-45934</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-45934</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation&lt;/p&gt;
&lt;p&gt;I have been observing a number of systems aborting at
insert_dev_extents() in btrfs_create_pending_block_groups(). The
following is a sample stack trace of such an abort coming from forced
chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this
can theoretically happen to any DUP chunk allocation.&lt;/p&gt;
&lt;p&gt;[81.801] ------------[ cut here ]------------
  [81.801] BTRFS: Transaction aborted (error -17)
  [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319
  [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk
  [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE
  [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014
  [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]
  [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282
  [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000
  [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0
  [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007
  [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000
  [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000
  [81.809] FS:  00007fec6bd…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation&lt;/p&gt;
&lt;p&gt;I have been observing a number of systems aborting at
insert_dev_extents() in btrfs_create_pending_block_groups(). The
following is a sample stack trace of such an abort coming from forced
chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this
can theoretically happen to any DUP chunk allocation.&lt;/p&gt;
&lt;p&gt;[81.801] ------------[ cut here ]------------
  [81.801] BTRFS: Transaction aborted (error -17)
  [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319
  [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk
  [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE
  [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014
  [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]
  [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282
  [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000
  [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0
  [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007
  [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000
  [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000
  [81.809] FS:  00007fec6bd…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-45934</guid>
    </item>
    <item>
      <title>GHSA-62rp-r79h-7q8x</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-62rp-r79h-7q8x</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation&lt;/p&gt;
&lt;p&gt;I have been observing a number of systems aborting at
insert_dev_extents() in btrfs_create_pending_block_groups(). The
following is a sample stack trace of such an abort coming from forced
chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this
can theoretically happen to any DUP chunk allocation.&lt;/p&gt;
&lt;p&gt;[81.801] ------------[ cut here ]------------
  [81.801] BTRFS: Transaction aborted (error -17)
  [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319
  [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk
  [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE
  [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014
  [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]
  [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282
  [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000
  [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0
  [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007
  [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000
  [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000
  [81.809] FS:  00007fec6bd…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation&lt;/p&gt;
&lt;p&gt;I have been observing a number of systems aborting at
insert_dev_extents() in btrfs_create_pending_block_groups(). The
following is a sample stack trace of such an abort coming from forced
chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this
can theoretically happen to any DUP chunk allocation.&lt;/p&gt;
&lt;p&gt;[81.801] ------------[ cut here ]------------
  [81.801] BTRFS: Transaction aborted (error -17)
  [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319
  [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk
  [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE
  [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014
  [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]
  [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282
  [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000
  [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0
  [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007
  [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000
  [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000
  [81.809] FS:  00007fec6bd…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-62rp-r79h-7q8x</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-45934 — btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-45934</link>
      <description>msrc_CVE-2026-45934</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-45934</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-45934</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45934</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 233 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation I have been observing a number of systems aborting at insert_dev_extents() in btrfs_create_pending_block_groups(). The following is a sample stack trace of such an abort coming from forced chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this can theoretically happen to any DUP chunk allocation.   [81.801] ------------[ cut here ]------------   [81.801] BTRFS: Transaction aborted (error -17)   [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319   [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk   [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE   [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014   [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]   [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282   [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000   [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0   [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007   [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000   [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000   [81.809] FS:  00007fec6bdd97…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 233 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation I have been observing a number of systems aborting at insert_dev_extents() in btrfs_create_pending_block_groups(). The following is a sample stack trace of such an abort coming from forced chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this can theoretically happen to any DUP chunk allocation.   [81.801] ------------[ cut here ]------------   [81.801] BTRFS: Transaction aborted (error -17)   [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319   [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk   [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE   [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014   [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]   [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282   [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000   [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0   [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007   [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000   [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000   [81.809] FS:  00007fec6bdd97…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-45934</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
