https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 06:18:14 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-09179 bdu:2024-09179 https://cve.radiocsirt.org/vuln/bdu:2024-09179 https://cve.radiocsirt.org/vuln/bell-cve-2024-26832 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-26832 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0526 certfr-2024-avi-0526 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0526 https://cve.radiocsirt.org/vuln/euvd-2026-320555 EUVD-2026-320555 https://cve.radiocsirt.org/vuln/euvd-2026-320555 https://cve.radiocsirt.org/vuln/fkie_cve-2024-26832 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm: zswap: fix missing folio cleanup in writeback race path</p> <p>In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit.</p> <p>However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref&#39;d. Make sure to unlock and put the folio before returning.</p> <p>This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm: zswap: fix missing folio cleanup in writeback race path</p> <p>In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit.</p> <p>However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref&#39;d. Make sure to unlock and put the folio before returning.</p> <p>This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-26832 https://cve.radiocsirt.org/vuln/ghsa-fpqf-cxvg-rf89 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm: zswap: fix missing folio cleanup in writeback race path</p> <p>In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit.</p> <p>However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref&#39;d. Make sure to unlock and put the folio before returning.</p> <p>This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>mm: zswap: fix missing folio cleanup in writeback race path</p> <p>In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit.</p> <p>However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref&#39;d. Make sure to unlock and put the folio before returning.</p> <p>This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.</p> https://cve.radiocsirt.org/vuln/ghsa-fpqf-cxvg-rf89 https://cve.radiocsirt.org/vuln/gsd-2024-26832 gsd-2024-26832 https://cve.radiocsirt.org/vuln/gsd-2024-26832 https://cve.radiocsirt.org/vuln/suse-su-2024:2135-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:2135-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26832 <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 66 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref&#39;d. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.</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 66 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref&#39;d. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26832 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0920 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand herbeizuführen oder einen nicht spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0920