https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 16:28:18 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-03772 bdu:2024-03772 https://cve.radiocsirt.org/vuln/bdu:2024-03772 https://cve.radiocsirt.org/vuln/bell-cve-2024-26800 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://cve.radiocsirt.org/vuln/bell-cve-2024-26800 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0334 certfr-2024-avi-0334 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0334 https://cve.radiocsirt.org/vuln/euvd-2026-345520 EUVD-2026-345520 https://cve.radiocsirt.org/vuln/euvd-2026-345520 https://cve.radiocsirt.org/vuln/fkie_cve-2024-26800 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tls: fix use-after-free on failed backlog decryption</p> <p>When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done.</p> <p>The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the memory has already been released.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tls: fix use-after-free on failed backlog decryption</p> <p>When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done.</p> <p>The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the memory has already been released.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-26800 https://cve.radiocsirt.org/vuln/ghsa-q4hp-86wf-hj44 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tls: fix use-after-free on failed backlog decryption</p> <p>When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done.</p> <p>The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the memory has already been released.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tls: fix use-after-free on failed backlog decryption</p> <p>When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done.</p> <p>The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the memory has already been released.</p> https://cve.radiocsirt.org/vuln/ghsa-q4hp-86wf-hj44 https://cve.radiocsirt.org/vuln/gsd-2024-26800 gsd-2024-26800 https://cve.radiocsirt.org/vuln/gsd-2024-26800 https://cve.radiocsirt.org/vuln/msrc_cve-2024-26800 msrc_CVE-2024-26800 https://cve.radiocsirt.org/vuln/msrc_cve-2024-26800 https://cve.radiocsirt.org/vuln/suse-su-2024:2893-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:2893-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26800 <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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 122 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the memory has already been released.</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 122 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: tls: fix use-after-free on failed backlog decryption When the decrypt request goes to the backlog and crypto_aead_decrypt returns -EBUSY, tls_do_decryption will wait until all async decryptions have completed. If one of them fails, tls_do_decryption will return -EBADMSG and tls_decrypt_sg jumps to the error path, releasing all the pages. But the pages have been passed to the async callback, and have already been released by tls_decrypt_done. The only true async case is when crypto_aead_decrypt returns -EINPROGRESS. With -EBUSY, we already waited so we can tell tls_sw_recvmsg that the data is available for immediate copy, but we need to notify tls_decrypt_sg (via the new -&gt;async_done flag) that the memory has already been released.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-26800 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0773 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen, seine Privilegien eskalieren oder einen nicht näher spezifizierten Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen, seine Privilegien eskalieren oder einen nicht näher spezifizierten Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-0773