https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 04:43:05 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-02974 bdu:2025-02974 https://cve.radiocsirt.org/vuln/bdu:2025-02974 https://cve.radiocsirt.org/vuln/bell-cve-2024-42231 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-42231 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0957 certfr-2024-avi-0957 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0957 https://cve.radiocsirt.org/vuln/euvd-2026-313078 EUVD-2026-313078 https://cve.radiocsirt.org/vuln/euvd-2026-313078 https://cve.radiocsirt.org/vuln/fkie_cve-2024-42231 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: zoned: fix calc_available_free_space() for zoned mode</p> <p>calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places.</p> <p>First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo-&gt;chunk_size) as it is.</p> <p>Second, the result &#34;avail&#34; may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process.</p> <p>This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: zoned: fix calc_available_free_space() for zoned mode</p> <p>calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places.</p> <p>First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo-&gt;chunk_size) as it is.</p> <p>Second, the result &#34;avail&#34; may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process.</p> <p>This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-42231 https://cve.radiocsirt.org/vuln/ghsa-hmvx-mw63-jvg7 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: zoned: fix calc_available_free_space() for zoned mode</p> <p>calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places.</p> <p>First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo-&gt;chunk_size) as it is.</p> <p>Second, the result &#34;avail&#34; may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process.</p> <p>This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>btrfs: zoned: fix calc_available_free_space() for zoned mode</p> <p>calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places.</p> <p>First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo-&gt;chunk_size) as it is.</p> <p>Second, the result &#34;avail&#34; may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process.</p> <p>This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.</p> https://cve.radiocsirt.org/vuln/ghsa-hmvx-mw63-jvg7 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42231 <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 88 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix calc_available_free_space() for zoned mode calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places. First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo-&gt;chunk_size) as it is. Second, the result &#34;avail&#34; may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process. This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.</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 88 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix calc_available_free_space() for zoned mode calc_available_free_space() returns the total size of metadata (or system) block groups, which can be allocated from unallocated disk space. The logic is wrong on zoned mode in two places. First, the calculation of data_chunk_size is wrong. We always allocate one zone as one chunk, and no partial allocation of a zone. So, we should use zone_size (= data_sinfo-&gt;chunk_size) as it is. Second, the result &#34;avail&#34; may not be zone aligned. Since we always allocate one zone as one chunk on zoned mode, returning non-zone size aligned bytes will result in less pressure on the async metadata reclaim process. This is serious for the nearly full state with a large zone size device. Allowing over-commit too much will result in less async reclaim work and end up in ENOSPC. We can align down to the zone size to avoid that.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42231 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1722 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1722