https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 13:06:07 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-12307 bdu:2026-12307 https://cve.radiocsirt.org/vuln/bdu:2026-12307 https://cve.radiocsirt.org/vuln/bell-cve-2026-23287 <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-2026-23287 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0547 certfr-2026-avi-0547 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0547 https://cve.radiocsirt.org/vuln/euvd-2026-364679 EUVD-2026-364679 https://cve.radiocsirt.org/vuln/euvd-2026-364679 https://cve.radiocsirt.org/vuln/fkie_cve-2026-23287 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>irqchip/sifive-plic: Fix frozen interrupt due to affinity setting</p> <p>PLIC ignores interrupt completion message for disabled interrupt, explained by the specification:</p> <p>The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored.</p> <p>This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled().</p> <p>However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt.</p> <p>This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt&#39;s affinity setting. The uart port becomes frozen almost instantaneously.</p> <p>Fix this by checking PLIC&#39;s enable bit instead of irqd_irq_disabled().</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>irqchip/sifive-plic: Fix frozen interrupt due to affinity setting</p> <p>PLIC ignores interrupt completion message for disabled interrupt, explained by the specification:</p> <p>The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored.</p> <p>This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled().</p> <p>However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt.</p> <p>This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt&#39;s affinity setting. The uart port becomes frozen almost instantaneously.</p> <p>Fix this by checking PLIC&#39;s enable bit instead of irqd_irq_disabled().</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-23287 https://cve.radiocsirt.org/vuln/ghsa-73mm-44q3-cmm6 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>irqchip/sifive-plic: Fix frozen interrupt due to affinity setting</p> <p>PLIC ignores interrupt completion message for disabled interrupt, explained by the specification:</p> <p>The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored.</p> <p>This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled().</p> <p>However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt.</p> <p>This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt&#39;s affinity setting. The uart port becomes frozen almost instantaneously.</p> <p>Fix this by checking PLIC&#39;s enable bit instead of irqd_irq_disabled().</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>irqchip/sifive-plic: Fix frozen interrupt due to affinity setting</p> <p>PLIC ignores interrupt completion message for disabled interrupt, explained by the specification:</p> <p>The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored.</p> <p>This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled().</p> <p>However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt.</p> <p>This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt&#39;s affinity setting. The uart port becomes frozen almost instantaneously.</p> <p>Fix this by checking PLIC&#39;s enable bit instead of irqd_irq_disabled().</p> https://cve.radiocsirt.org/vuln/ghsa-73mm-44q3-cmm6 https://cve.radiocsirt.org/vuln/icsa-26-209-04 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/icsa-26-209-04 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23287 msrc_CVE-2026-23287 https://cve.radiocsirt.org/vuln/msrc_cve-2026-23287 https://cve.radiocsirt.org/vuln/ssa-019113 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/ssa-019113 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23287 <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 205 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: irqchip/sifive-plic: Fix frozen interrupt due to affinity setting PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt&#39;s affinity setting. The uart port becomes frozen almost instantaneously. Fix this by checking PLIC&#39;s enable bit instead of irqd_irq_disabled().</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 205 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: irqchip/sifive-plic: Fix frozen interrupt due to affinity setting PLIC ignores interrupt completion message for disabled interrupt, explained by the specification: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that is currently enabled for the target, the completion is silently ignored. This caused problems in the past, because an interrupt can be disabled while still being handled and plic_irq_eoi() had no effect. That was fixed by checking if the interrupt is disabled, and if so enable it, before sending the completion message. That check is done with irqd_irq_disabled(). However, that is not sufficient because the enable bit for the handling hart can be zero despite irqd_irq_disabled(d) being false. This can happen when affinity setting is changed while a hart is still handling the interrupt. This problem is easily reproducible by dumping a large file to uart (which generates lots of interrupts) and at the same time keep changing the uart interrupt&#39;s affinity setting. The uart port becomes frozen almost instantaneously. Fix this by checking PLIC&#39;s enable bit instead of irqd_irq_disabled().</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23287 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service zu verursachen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, weitere nicht spezifizierte Auswirkungen zu verursachen und potentiell Code auszuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0861