https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 20:28:49 +0000 https://cve.radiocsirt.org/vuln/bdu:2021-02595 bdu:2021-02595 https://cve.radiocsirt.org/vuln/bdu:2021-02595 https://cve.radiocsirt.org/vuln/bell-cve-2021-26932 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://cve.radiocsirt.org/vuln/bell-cve-2021-26932 https://cve.radiocsirt.org/vuln/certfr-2021-avi-152 certfr-2021-avi-152 https://cve.radiocsirt.org/vuln/certfr-2021-avi-152 https://cve.radiocsirt.org/vuln/cnvd-2021-21916 cnvd-2021-21916 https://cve.radiocsirt.org/vuln/cnvd-2021-21916 https://cve.radiocsirt.org/vuln/euvd-2026-25232 EUVD-2026-25232 https://cve.radiocsirt.org/vuln/euvd-2026-25232 https://cve.radiocsirt.org/vuln/fkie_cve-2021-26932 <p>An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.</p> <p>An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2021-26932 https://cve.radiocsirt.org/vuln/ghsa-w8vm-5jg7-3r38 <p>An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.</p> <p>An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.</p> https://cve.radiocsirt.org/vuln/ghsa-w8vm-5jg7-3r38 https://cve.radiocsirt.org/vuln/gsd-2021-26932 gsd-2021-26932 https://cve.radiocsirt.org/vuln/gsd-2021-26932 https://cve.radiocsirt.org/vuln/msrc_cve-2021-26932 msrc_CVE-2021-26932 https://cve.radiocsirt.org/vuln/msrc_cve-2021-26932 https://cve.radiocsirt.org/vuln/oesa-2021-1111 <p><strong>Affected:</strong> openEuler:20.03-LTS: kernel, openEuler:20.03-LTS-SP1: kernel</p> <p>The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. Security Fix(es): An issue was discovered in the Linux kernel 2.6.39 through 5.10.16, as used in Xen. Block, net, and SCSI backends consider certain errors a plain bug, deliberately causing a kernel crash. For errors potentially being at least under the influence of guests (such as out of memory conditions), it isn&amp;apos;t correct to assume a plain bug. Memory allocations potentially causing such crashes occur only when Linux is running in PV mode, though. This affects drivers/block/xen-blkback/blkback.c and drivers/xen/xen-scsiback.c.(CVE-2021-26931) An issue was discovered in the Linux kernel 3.11 through 5.10.16, as used by Xen. To service requests to the PV backend, the driver maps grant references provided by the frontend. In this process, errors may be encountered. In one case, an error encountered earlier might be discarded by later processing, resulting in the caller assuming successful mapping, and hence subsequent operations trying to access space that wasn&amp;apos;t mapped. In another case, internal state would be insufficiently updated, preventing safe recovery from the error. This affects drivers/block/xen-blkback/blkback.c.(CVE-2021-26930) An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant map…</p> <p><strong>Affected:</strong> openEuler:20.03-LTS: kernel, openEuler:20.03-LTS-SP1: kernel</p> <p>The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc. Security Fix(es): An issue was discovered in the Linux kernel 2.6.39 through 5.10.16, as used in Xen. Block, net, and SCSI backends consider certain errors a plain bug, deliberately causing a kernel crash. For errors potentially being at least under the influence of guests (such as out of memory conditions), it isn&amp;apos;t correct to assume a plain bug. Memory allocations potentially causing such crashes occur only when Linux is running in PV mode, though. This affects drivers/block/xen-blkback/blkback.c and drivers/xen/xen-scsiback.c.(CVE-2021-26931) An issue was discovered in the Linux kernel 3.11 through 5.10.16, as used by Xen. To service requests to the PV backend, the driver maps grant references provided by the frontend. In this process, errors may be encountered. In one case, an error encountered earlier might be discarded by later processing, resulting in the caller assuming successful mapping, and hence subsequent operations trying to access space that wasn&amp;apos;t mapped. In another case, internal state would be insufficiently updated, preventing safe recovery from the error. This affects drivers/block/xen-blkback/blkback.c.(CVE-2021-26930) An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant map…</p> https://cve.radiocsirt.org/vuln/oesa-2021-1111 https://cve.radiocsirt.org/vuln/opensuse-su-2021:0393-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2021:0393-1 https://cve.radiocsirt.org/vuln/suse-su-2021:0735-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2021:0735-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-26932 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:16.04:LTS: linux, Ubuntu:16.04:LTS: linux-aws, Ubuntu:16.04:LTS: linux-kvm, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp and 79 more</p> <p>An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:16.04:LTS: linux, Ubuntu:16.04:LTS: linux-aws, Ubuntu:16.04:LTS: linux-kvm, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp and 79 more</p> <p>An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-26932