<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 12:35:37 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-04412</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-04412</link>
      <description>bdu:2025-04412</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-04412</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-50196</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-50196</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-50196</guid>
    </item>
    <item>
      <title>certfr-2024-avi-1102 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-1102</link>
      <description>certfr-2024-avi-1102</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-1102</guid>
    </item>
    <item>
      <title>EUVD-2026-313528</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313528</link>
      <description>EUVD-2026-313528</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313528</guid>
    </item>
    <item>
      <title>fkie_cve-2024-50196</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-50196</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pinctrl: ocelot: fix system hang on level based interrupts&lt;/p&gt;
&lt;p&gt;The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.&lt;/p&gt;
&lt;p&gt;```
for (i = 0; i &amp;lt; info-&amp;gt;stride; i++) {
	uregmap_read(info-&amp;gt;map, id_reg + 4 * i, &amp;amp;reg);
	if (!reg)
		continue;&lt;/p&gt;
&lt;p&gt;chained_irq_enter(parent_chip, desc);
```&lt;/p&gt;
&lt;p&gt;However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.&lt;/p&gt;
&lt;p&gt;Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.&lt;/p&gt;
&lt;p&gt;The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pinctrl: ocelot: fix system hang on level based interrupts&lt;/p&gt;
&lt;p&gt;The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.&lt;/p&gt;
&lt;p&gt;```
for (i = 0; i &amp;lt; info-&amp;gt;stride; i++) {
	uregmap_read(info-&amp;gt;map, id_reg + 4 * i, &amp;amp;reg);
	if (!reg)
		continue;&lt;/p&gt;
&lt;p&gt;chained_irq_enter(parent_chip, desc);
```&lt;/p&gt;
&lt;p&gt;However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.&lt;/p&gt;
&lt;p&gt;Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.&lt;/p&gt;
&lt;p&gt;The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-50196</guid>
    </item>
    <item>
      <title>GHSA-3vv9-rrp8-6jqf</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3vv9-rrp8-6jqf</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pinctrl: ocelot: fix system hang on level based interrupts&lt;/p&gt;
&lt;p&gt;The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.&lt;/p&gt;
&lt;p&gt;```
for (i = 0; i &amp;lt; info-&amp;gt;stride; i++) {
	uregmap_read(info-&amp;gt;map, id_reg + 4 * i, &amp;amp;reg);
	if (!reg)
		continue;&lt;/p&gt;
&lt;p&gt;chained_irq_enter(parent_chip, desc);
```&lt;/p&gt;
&lt;p&gt;However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.&lt;/p&gt;
&lt;p&gt;Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.&lt;/p&gt;
&lt;p&gt;The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;pinctrl: ocelot: fix system hang on level based interrupts&lt;/p&gt;
&lt;p&gt;The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.&lt;/p&gt;
&lt;p&gt;```
for (i = 0; i &amp;lt; info-&amp;gt;stride; i++) {
	uregmap_read(info-&amp;gt;map, id_reg + 4 * i, &amp;amp;reg);
	if (!reg)
		continue;&lt;/p&gt;
&lt;p&gt;chained_irq_enter(parent_chip, desc);
```&lt;/p&gt;
&lt;p&gt;However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.&lt;/p&gt;
&lt;p&gt;Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.&lt;/p&gt;
&lt;p&gt;The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3vv9-rrp8-6jqf</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-50196 — pinctrl: ocelot: fix system hang on level based interrupts</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-50196</link>
      <description>msrc_CVE-2024-50196</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-50196</guid>
    </item>
    <item>
      <title>OESA-2024-2518 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2518</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
serial: sc16is7xx: fix invalid FIFO access with special register set&#13;
&#13;
When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.&#13;
&#13;
Call graph example:
    sc16is7xx_startup(): entry
    sc16is7xx_ms_proc(): entry
    sc16is7xx_set_termios(): entry
    sc16is7xx_set_baud(): DLH/DLL = $009C --&amp;amp;gt; access special register set
    sc16is7xx_port_irq() entry            --&amp;amp;gt; IIR is 0x0C
    sc16is7xx_handle_rx() entry
    sc16is7xx_fifo_read(): --&amp;amp;gt; unable to access FIFO (RHR) because it is
                               mapped to DLL (LCR=LCR_CONF_MODE_A)
    sc16is7xx_set_baud(): exit --&amp;amp;gt; Restore access to general register set&#13;
&#13;
Fix the problem by claiming the efr_lock mutex when accessing the Special
register set.(CVE-2024-44950)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_index before accessing dc-&amp;amp;gt;links[]&#13;
&#13;
[WHY &amp;amp;amp; HOW]
dc-&amp;amp;gt;links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.&#13;
&#13;
This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)&#13;
&#13;
In the Linux kernel, the…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
serial: sc16is7xx: fix invalid FIFO access with special register set&#13;
&#13;
When enabling access to the special register set, Receiver time-out and
RHR interrupts can happen. In this case, the IRQ handler will try to read
from the FIFO thru the RHR register at address 0x00, but address 0x00 is
mapped to DLL register, resulting in erroneous FIFO reading.&#13;
&#13;
Call graph example:
    sc16is7xx_startup(): entry
    sc16is7xx_ms_proc(): entry
    sc16is7xx_set_termios(): entry
    sc16is7xx_set_baud(): DLH/DLL = $009C --&amp;amp;gt; access special register set
    sc16is7xx_port_irq() entry            --&amp;amp;gt; IIR is 0x0C
    sc16is7xx_handle_rx() entry
    sc16is7xx_fifo_read(): --&amp;amp;gt; unable to access FIFO (RHR) because it is
                               mapped to DLL (LCR=LCR_CONF_MODE_A)
    sc16is7xx_set_baud(): exit --&amp;amp;gt; Restore access to general register set&#13;
&#13;
Fix the problem by claiming the efr_lock mutex when accessing the Special
register set.(CVE-2024-44950)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
drm/amd/display: Check link_index before accessing dc-&amp;amp;gt;links[]&#13;
&#13;
[WHY &amp;amp;amp; HOW]
dc-&amp;amp;gt;links[] has max size of MAX_LINKS and NULL is return when trying to
access with out-of-bound index.&#13;
&#13;
This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.(CVE-2024-46813)&#13;
&#13;
In the Linux kernel, the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2518</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:14500-1 — kernel-devel-6.11.8-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</link>
      <description>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-6.11.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:14500-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:4314-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:4314-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:4314-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-50196</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50196</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 167 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i &amp;lt; info-&amp;gt;stride; i++) { 	uregmap_read(info-&amp;gt;map, id_reg + 4 * i, &amp;amp;reg); 	if (!reg) 		continue; 	chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 167 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i &amp;lt; info-&amp;gt;stride; i++) { 	uregmap_read(info-&amp;gt;map, id_reg + 4 * i, &amp;amp;reg); 	if (!reg) 		continue; 	chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-50196</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3376 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3376</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen und einen Denial-of-Service-Zustand zu erzeugen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen und einen Denial-of-Service-Zustand zu erzeugen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3376</guid>
    </item>
  </channel>
</rss>
