<?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://vulnerability.circl.lu</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>Tue, 29 Sep 2026 04:30:09 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-39752 — ARM: rockchip: fix kernel hang during smp initialization</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2025-39752</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC CN 4100&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ARM: rockchip: fix kernel hang during smp initialization&lt;/p&gt;
&lt;p&gt;In order to bring up secondary CPUs main CPU write trampoline
code to SRAM. The trampoline code is written while secondary
CPUs are powered on (at least that true for RK3188 CPU).
Sometimes that leads to kernel hang. Probably because secondary
CPU execute trampoline code while kernel doesn&amp;#39;t expect.&lt;/p&gt;
&lt;p&gt;The patch moves SRAM initialization step to the point where all
secondary CPUs are powered down.&lt;/p&gt;
&lt;p&gt;That fixes rarely hangs on RK3188:
[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.091996] rockchip_smp_prepare_cpus: ncores 4&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC CN 4100&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;ARM: rockchip: fix kernel hang during smp initialization&lt;/p&gt;
&lt;p&gt;In order to bring up secondary CPUs main CPU write trampoline
code to SRAM. The trampoline code is written while secondary
CPUs are powered on (at least that true for RK3188 CPU).
Sometimes that leads to kernel hang. Probably because secondary
CPU execute trampoline code while kernel doesn&amp;#39;t expect.&lt;/p&gt;
&lt;p&gt;The patch moves SRAM initialization step to the point where all
secondary CPUs are powered down.&lt;/p&gt;
&lt;p&gt;That fixes rarely hangs on RK3188:
[    0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.091996] rockchip_smp_prepare_cpus: ncores 4&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2025-39752</guid>
    </item>
  </channel>
</rss>
