https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 00:49:43 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-03378 bdu:2026-03378 https://cve.radiocsirt.org/vuln/bdu:2026-03378 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0587 certfr-2025-avi-0587 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0587 https://cve.radiocsirt.org/vuln/euvd-2026-344831 EUVD-2026-344831 https://cve.radiocsirt.org/vuln/euvd-2026-344831 https://cve.radiocsirt.org/vuln/fkie_cve-2022-49999 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix space cache corruption and potential double allocations</p> <p>When testing space_cache v2 on a large set of machines, we encountered a few symptoms:</p> <p>1. &#34;unable to add free space :-17&#34; (EEXIST) errors. 2. Missing free space info items, sometimes caught with a &#34;missing free space info for X&#34; error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree.</p> <p>All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e (&#34;btrfs: make concurrent fsyncs wait less…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix space cache corruption and potential double allocations</p> <p>When testing space_cache v2 on a large set of machines, we encountered a few symptoms:</p> <p>1. &#34;unable to add free space :-17&#34; (EEXIST) errors. 2. Missing free space info items, sometimes caught with a &#34;missing free space info for X&#34; error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree.</p> <p>All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e (&#34;btrfs: make concurrent fsyncs wait less…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-49999 https://cve.radiocsirt.org/vuln/ghsa-j8xg-f23q-2vmv <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix space cache corruption and potential double allocations</p> <p>When testing space_cache v2 on a large set of machines, we encountered a few symptoms:</p> <p>1. &#34;unable to add free space :-17&#34; (EEXIST) errors. 2. Missing free space info items, sometimes caught with a &#34;missing free space info for X&#34; error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree.</p> <p>All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e (&#34;btrfs: make concurrent fsyncs wait less…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: fix space cache corruption and potential double allocations</p> <p>When testing space_cache v2 on a large set of machines, we encountered a few symptoms:</p> <p>1. &#34;unable to add free space :-17&#34; (EEXIST) errors. 2. Missing free space info items, sometimes caught with a &#34;missing free space info for X&#34; error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree.</p> <p>All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e (&#34;btrfs: make concurrent fsyncs wait less…</p> https://cve.radiocsirt.org/vuln/ghsa-j8xg-f23q-2vmv https://cve.radiocsirt.org/vuln/suse-su-2025:02264-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:02264-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49999 <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 94 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: fix space cache corruption and potential double allocations When testing space_cache v2 on a large set of machines, we encountered a few symptoms: 1. &#34;unable to add free space :-17&#34; (EEXIST) errors. 2. Missing free space info items, sometimes caught with a &#34;missing free space info for X&#34; error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree. All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e (&#34;btrfs: make concurrent fsyncs wait less when…</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 94 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: fix space cache corruption and potential double allocations When testing space_cache v2 on a large set of machines, we encountered a few symptoms: 1. &#34;unable to add free space :-17&#34; (EEXIST) errors. 2. Missing free space info items, sometimes caught with a &#34;missing free space info for X&#34; error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter made it onto disk, the next reboot would hit the BUG_ON() in add_new_free_space(). 4. On some hosts with no on-disk corruption or error messages, the in-memory space cache (dumped with drgn) disagreed with the free space tree. All of these symptoms have the same underlying cause: a race between caching the free space for a block group and returning free space to the in-memory space cache for pinned extents causes us to double-add a free range to the space cache. This race exists when free space is cached from the free space tree (space_cache=v2) or the extent tree (nospace_cache, or space_cache=v1 if the cache needs to be regenerated). struct btrfs_block_group::last_byte_to_unpin and struct btrfs_block_group::progress are supposed to protect against this race, but commit d0c2f4fa555e (&#34;btrfs: make concurrent fsyncs wait less when…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49999 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350 <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350