https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 09 Nov 2026 17:49:01 +0000 https://db.gcve.eu/vuln/certfr-2026-avi-1469 certfr-2026-avi-1469 https://db.gcve.eu/vuln/certfr-2026-avi-1469 https://db.gcve.eu/vuln/fkie_cve-2026-98930 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: s390: Fix IRQ injection with SIGP Stop and Store Status</p> <p>When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL.</p> <p>If the vCPU is already stopped, the status is stored immediately.</p> <p>Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue.</p> <p>Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock.</p> <p>Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free().</p> <p>[ Added Fixes tag while picking -- Claudio ]</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: s390: Fix IRQ injection with SIGP Stop and Store Status</p> <p>When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL.</p> <p>If the vCPU is already stopped, the status is stored immediately.</p> <p>Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue.</p> <p>Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock.</p> <p>Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free().</p> <p>[ Added Fixes tag while picking -- Claudio ]</p> https://db.gcve.eu/vuln/fkie_cve-2026-98930 https://db.gcve.eu/vuln/ghsa-hqr4-mv6v-vc35 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: s390: Fix IRQ injection with SIGP Stop and Store Status</p> <p>When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL.</p> <p>If the vCPU is already stopped, the status is stored immediately.</p> <p>Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue.</p> <p>Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock.</p> <p>Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free().</p> <p>[ Added Fixes tag while picking -- Claudio ]</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>KVM: s390: Fix IRQ injection with SIGP Stop and Store Status</p> <p>When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL.</p> <p>If the vCPU is already stopped, the status is stored immediately.</p> <p>Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue.</p> <p>Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock.</p> <p>Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free().</p> <p>[ Added Fixes tag while picking -- Claudio ]</p> https://db.gcve.eu/vuln/ghsa-hqr4-mv6v-vc35 https://db.gcve.eu/vuln/msrc_cve-2026-98930 msrc_CVE-2026-98930 https://db.gcve.eu/vuln/msrc_cve-2026-98930 https://db.gcve.eu/vuln/ubuntu-cve-2026-98930 <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:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 247 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix IRQ injection with SIGP Stop and Store Status When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL. If the vCPU is already stopped, the status is stored immediately. Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue. Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock. Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free(). [ Added Fixes tag while picking -- Claudio ]</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:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 247 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix IRQ injection with SIGP Stop and Store Status When __inject_sigp_stop() is called for a Stop and Store Status operation, if the vCPU is running, the interrupt is marked as pending and the status is stored by the thread performing the KVM_RUN IOCTL. If the vCPU is already stopped, the status is stored immediately. Storing the status means writing into userspace, which might fault, and __inject_sigp_stop() is called from do_inject_vcpu() which in turn is always called holding a spinlock, which is obviously an issue. Fix this by returning -EWOULDBLOCK from __inject_sigp_stop(), and adding a bool flag to indicate whether a store status is needed. The callers of do_inject_vcpu() are modified to pass the pointer to the bool flag; whenever a Store Status operation is needed, the callers can now perform it outside the spinlock. Opportunistically refactor kvm_s390_set_irq_state() to use scoped_guard() and __free(). [ Added Fixes tag while picking -- Claudio ]</p> https://db.gcve.eu/vuln/ubuntu-cve-2026-98930 https://db.gcve.eu/vuln/wid-sec-w-2026-4152 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.</p> https://db.gcve.eu/vuln/wid-sec-w-2026-4152