<?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>Sun, 04 Oct 2026 13:51:48 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-01764</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-01764</link>
      <description>bdu:2025-01764</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-01764</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-46706</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-46706</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-46706</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0870 — 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-0870</link>
      <description>certfr-2024-avi-0870</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0870</guid>
    </item>
    <item>
      <title>cnvd-2024-39373</title>
      <link>https://cve.radiocsirt.org/vuln/cnvd-2024-39373</link>
      <description>cnvd-2024-39373</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cnvd-2024-39373</guid>
    </item>
    <item>
      <title>EUVD-2026-313236</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313236</link>
      <description>EUVD-2026-313236</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313236</guid>
    </item>
    <item>
      <title>fkie_cve-2024-46706</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-46706</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tty: serial: fsl_lpuart: mark last busy before uart_add_one_port&lt;/p&gt;
&lt;p&gt;With &amp;#34;earlycon initcall_debug=1 loglevel=8&amp;#34; in bootargs, kernel
sometimes boot hang. It is because normal console still is not ready,
but runtime suspend is called, so early console putchar will hang
in waiting TRDE set in UARTSTAT.&lt;/p&gt;
&lt;p&gt;The lpuart driver has auto suspend delay set to 3000ms, but during
uart_add_one_port, a child device serial ctrl will added and probed with
its pm runtime enabled(see serial_ctrl.c).
The runtime suspend call path is:
device_add
     |-&amp;gt; bus_probe_device
           |-&amp;gt;device_initial_probe
	           |-&amp;gt;__device_attach
                         |-&amp;gt; pm_runtime_get_sync(dev-&amp;gt;parent);
			 |-&amp;gt; pm_request_idle(dev);
			 |-&amp;gt; pm_runtime_put(dev-&amp;gt;parent);&lt;/p&gt;
&lt;p&gt;So in the end, before normal console ready, the lpuart get runtime
suspended. And earlycon putchar will hang.&lt;/p&gt;
&lt;p&gt;To address the issue, mark last busy just after pm_runtime_enable,
three seconds is long enough to switch from bootconsole to normal
console.&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;tty: serial: fsl_lpuart: mark last busy before uart_add_one_port&lt;/p&gt;
&lt;p&gt;With &amp;#34;earlycon initcall_debug=1 loglevel=8&amp;#34; in bootargs, kernel
sometimes boot hang. It is because normal console still is not ready,
but runtime suspend is called, so early console putchar will hang
in waiting TRDE set in UARTSTAT.&lt;/p&gt;
&lt;p&gt;The lpuart driver has auto suspend delay set to 3000ms, but during
uart_add_one_port, a child device serial ctrl will added and probed with
its pm runtime enabled(see serial_ctrl.c).
The runtime suspend call path is:
device_add
     |-&amp;gt; bus_probe_device
           |-&amp;gt;device_initial_probe
	           |-&amp;gt;__device_attach
                         |-&amp;gt; pm_runtime_get_sync(dev-&amp;gt;parent);
			 |-&amp;gt; pm_request_idle(dev);
			 |-&amp;gt; pm_runtime_put(dev-&amp;gt;parent);&lt;/p&gt;
&lt;p&gt;So in the end, before normal console ready, the lpuart get runtime
suspended. And earlycon putchar will hang.&lt;/p&gt;
&lt;p&gt;To address the issue, mark last busy just after pm_runtime_enable,
three seconds is long enough to switch from bootconsole to normal
console.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-46706</guid>
    </item>
    <item>
      <title>GHSA-gggx-8wfw-w6jx</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gggx-8wfw-w6jx</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tty: serial: fsl_lpuart: mark last busy before uart_add_one_port&lt;/p&gt;
&lt;p&gt;With &amp;#34;earlycon initcall_debug=1 loglevel=8&amp;#34; in bootargs, kernel
sometimes boot hang. It is because normal console still is not ready,
but runtime suspend is called, so early console putchar will hang
in waiting TRDE set in UARTSTAT.&lt;/p&gt;
&lt;p&gt;The lpuart driver has auto suspend delay set to 3000ms, but during
uart_add_one_port, a child device serial ctrl will added and probed with
its pm runtime enabled(see serial_ctrl.c).
The runtime suspend call path is:
device_add
     |-&amp;gt; bus_probe_device
           |-&amp;gt;device_initial_probe
	           |-&amp;gt;__device_attach
                         |-&amp;gt; pm_runtime_get_sync(dev-&amp;gt;parent);
			 |-&amp;gt; pm_request_idle(dev);
			 |-&amp;gt; pm_runtime_put(dev-&amp;gt;parent);&lt;/p&gt;
&lt;p&gt;So in the end, before normal console ready, the lpuart get runtime
suspended. And earlycon putchar will hang.&lt;/p&gt;
&lt;p&gt;To address the issue, mark last busy just after pm_runtime_enable,
three seconds is long enough to switch from bootconsole to normal
console.&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;tty: serial: fsl_lpuart: mark last busy before uart_add_one_port&lt;/p&gt;
&lt;p&gt;With &amp;#34;earlycon initcall_debug=1 loglevel=8&amp;#34; in bootargs, kernel
sometimes boot hang. It is because normal console still is not ready,
but runtime suspend is called, so early console putchar will hang
in waiting TRDE set in UARTSTAT.&lt;/p&gt;
&lt;p&gt;The lpuart driver has auto suspend delay set to 3000ms, but during
uart_add_one_port, a child device serial ctrl will added and probed with
its pm runtime enabled(see serial_ctrl.c).
The runtime suspend call path is:
device_add
     |-&amp;gt; bus_probe_device
           |-&amp;gt;device_initial_probe
	           |-&amp;gt;__device_attach
                         |-&amp;gt; pm_runtime_get_sync(dev-&amp;gt;parent);
			 |-&amp;gt; pm_request_idle(dev);
			 |-&amp;gt; pm_runtime_put(dev-&amp;gt;parent);&lt;/p&gt;
&lt;p&gt;So in the end, before normal console ready, the lpuart get runtime
suspended. And earlycon putchar will hang.&lt;/p&gt;
&lt;p&gt;To address the issue, mark last busy just after pm_runtime_enable,
three seconds is long enough to switch from bootconsole to normal
console.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gggx-8wfw-w6jx</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-46706 — tty: serial: fsl_lpuart: mark last busy before uart_add_one_port</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-46706</link>
      <description>msrc_CVE-2024-46706</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-46706</guid>
    </item>
    <item>
      <title>OESA-2024-2181 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2181</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().&#13;
&#13;
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
with nice analysis.&#13;
&#13;
Since commit ec94c2696f0b (&amp;amp;quot;tcp/dccp: avoid one atomic operation for
timewait hashdance&amp;amp;quot;), inet_twsk_hashdance() sets TIME-WAIT socket&amp;amp;apos;s
sk_refcnt after putting it into ehash and releasing the bucket lock.&#13;
&#13;
Thus, there is a small race window where other threads could try to
reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
for the TIME-WAIT socket with zero refcnt.&#13;
&#13;
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
and sock_put() will cause underflow, triggering a real use-after-free
somewhere else.&#13;
&#13;
To avoid the use-after-free, we need to use refcount_inc_not_zero() in
tcp_twsk_unique() and give up on reusing the port if it returns false.&#13;
&#13;
[0]:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
RIP: 0010:refcount_warn_saturate+0xe5/0x110
Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS: 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;
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().&#13;
&#13;
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
with nice analysis.&#13;
&#13;
Since commit ec94c2696f0b (&amp;amp;quot;tcp/dccp: avoid one atomic operation for
timewait hashdance&amp;amp;quot;), inet_twsk_hashdance() sets TIME-WAIT socket&amp;amp;apos;s
sk_refcnt after putting it into ehash and releasing the bucket lock.&#13;
&#13;
Thus, there is a small race window where other threads could try to
reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
for the TIME-WAIT socket with zero refcnt.&#13;
&#13;
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
and sock_put() will cause underflow, triggering a real use-after-free
somewhere else.&#13;
&#13;
To avoid the use-after-free, we need to use refcount_inc_not_zero() in
tcp_twsk_unique() and give up on reusing the port if it returns false.&#13;
&#13;
[0]:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
RIP: 0010:refcount_warn_saturate+0xe5/0x110
Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2181</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:3551-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:3551-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:3551-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-46706</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46706</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: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 89 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: mark last busy before uart_add_one_port With &amp;#34;earlycon initcall_debug=1 loglevel=8&amp;#34; in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT. The lpuart driver has auto suspend delay set to 3000ms, but during uart_add_one_port, a child device serial ctrl will added and probed with its pm runtime enabled(see serial_ctrl.c). The runtime suspend call path is: device_add      |-&amp;gt; bus_probe_device            |-&amp;gt;device_initial_probe 	           |-&amp;gt;__device_attach                          |-&amp;gt; pm_runtime_get_sync(dev-&amp;gt;parent); 			 |-&amp;gt; pm_request_idle(dev); 			 |-&amp;gt; pm_runtime_put(dev-&amp;gt;parent); So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang. To address the issue, mark last busy just after pm_runtime_enable, three seconds is long enough to switch from bootconsole to normal console.&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: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 89 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tty: serial: fsl_lpuart: mark last busy before uart_add_one_port With &amp;#34;earlycon initcall_debug=1 loglevel=8&amp;#34; in bootargs, kernel sometimes boot hang. It is because normal console still is not ready, but runtime suspend is called, so early console putchar will hang in waiting TRDE set in UARTSTAT. The lpuart driver has auto suspend delay set to 3000ms, but during uart_add_one_port, a child device serial ctrl will added and probed with its pm runtime enabled(see serial_ctrl.c). The runtime suspend call path is: device_add      |-&amp;gt; bus_probe_device            |-&amp;gt;device_initial_probe 	           |-&amp;gt;__device_attach                          |-&amp;gt; pm_runtime_get_sync(dev-&amp;gt;parent); 			 |-&amp;gt; pm_request_idle(dev); 			 |-&amp;gt; pm_runtime_put(dev-&amp;gt;parent); So in the end, before normal console ready, the lpuart get runtime suspended. And earlycon putchar will hang. To address the issue, mark last busy just after pm_runtime_enable, three seconds is long enough to switch from bootconsole to normal console.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-46706</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-2133 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder einen unspezifischen Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-2133</guid>
    </item>
  </channel>
</rss>
