https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 15:14:40 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-07592 bdu:2024-07592 https://cve.radiocsirt.org/vuln/bdu:2024-07592 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0779 certfr-2024-avi-0779 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0779 https://cve.radiocsirt.org/vuln/euvd-2026-310219 EUVD-2026-310219 https://cve.radiocsirt.org/vuln/euvd-2026-310219 https://cve.radiocsirt.org/vuln/fkie_cve-2022-48890 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM</p> <p>storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can&#39;t do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force.</p> <p>Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM</p> <p>storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can&#39;t do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force.</p> <p>Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-48890 https://cve.radiocsirt.org/vuln/ghsa-7fhg-f25c-34r6 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM</p> <p>storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can&#39;t do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force.</p> <p>Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM</p> <p>storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can&#39;t do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force.</p> <p>Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.</p> https://cve.radiocsirt.org/vuln/ghsa-7fhg-f25c-34r6 https://cve.radiocsirt.org/vuln/suse-su-2024:3190-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:3190-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48890 <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 70 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can&#39;t do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force. Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.</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 70 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(), which in a confidential VM allocates swiotlb bounce buffers. If the I/O submission fails in storvsc_do_io(), the I/O is typically retried by higher level code, but the bounce buffer memory is never freed. The mostly like cause of I/O submission failure is a full VMBus channel ring buffer, which is not uncommon under high I/O loads. Eventually enough bounce buffer memory leaks that the confidential VM can&#39;t do any I/O. The same problem can arise in a non-confidential VM with kernel boot parameter swiotlb=force. Fix this by doing scsi_dma_unmap() in the case of an I/O submission error, which frees the bounce buffer memory.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-48890 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1888 <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder einen unspezifischen Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1888