<?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>Wed, 07 Oct 2026 23:37:56 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-13495</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-13495</link>
      <description>bdu:2025-13495</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-13495</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-38407</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-38407</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-2025-38407</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0922 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0922</link>
      <description>certfr-2025-avi-0922</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0922</guid>
    </item>
    <item>
      <title>EUVD-2026-314590</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314590</link>
      <description>EUVD-2026-314590</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314590</guid>
    </item>
    <item>
      <title>fkie_cve-2025-38407</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-38407</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: cpu_ops_sbi: Use static array for boot_data&lt;/p&gt;
&lt;p&gt;Since commit 6b9f29b81b15 (&amp;#34;riscv: Enable pcpu page first chunk
allocator&amp;#34;), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.&lt;/p&gt;
&lt;p&gt;In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.&lt;/p&gt;
&lt;p&gt;Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.&lt;/p&gt;
&lt;p&gt;This fixes NUMA=y SMP boot on Sophgo SG2042.&lt;/p&gt;
&lt;p&gt;To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:&lt;/p&gt;
&lt;p&gt;qemu-system-riscv64 -M virt -smp 2 -nographic \
    -kernel arch/riscv/boot/Image \
    -append &amp;#34;percpu_alloc=page&amp;#34;&lt;/p&gt;
&lt;p&gt;Kernel output:&lt;/p&gt;
&lt;p&gt;[    0.000000] Booting Linux on hartid 0
[    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[    0.083192] smp: Bringing up secondary CPUs ...
[    0.086722] ------------[ cut here ]------------
[    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)…&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;riscv: cpu_ops_sbi: Use static array for boot_data&lt;/p&gt;
&lt;p&gt;Since commit 6b9f29b81b15 (&amp;#34;riscv: Enable pcpu page first chunk
allocator&amp;#34;), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.&lt;/p&gt;
&lt;p&gt;In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.&lt;/p&gt;
&lt;p&gt;Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.&lt;/p&gt;
&lt;p&gt;This fixes NUMA=y SMP boot on Sophgo SG2042.&lt;/p&gt;
&lt;p&gt;To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:&lt;/p&gt;
&lt;p&gt;qemu-system-riscv64 -M virt -smp 2 -nographic \
    -kernel arch/riscv/boot/Image \
    -append &amp;#34;percpu_alloc=page&amp;#34;&lt;/p&gt;
&lt;p&gt;Kernel output:&lt;/p&gt;
&lt;p&gt;[    0.000000] Booting Linux on hartid 0
[    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[    0.083192] smp: Bringing up secondary CPUs ...
[    0.086722] ------------[ cut here ]------------
[    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-38407</guid>
    </item>
    <item>
      <title>GHSA-qq4v-pr8w-v8hg</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-qq4v-pr8w-v8hg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: cpu_ops_sbi: Use static array for boot_data&lt;/p&gt;
&lt;p&gt;Since commit 6b9f29b81b15 (&amp;#34;riscv: Enable pcpu page first chunk
allocator&amp;#34;), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.&lt;/p&gt;
&lt;p&gt;In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.&lt;/p&gt;
&lt;p&gt;Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.&lt;/p&gt;
&lt;p&gt;This fixes NUMA=y SMP boot on Sophgo SG2042.&lt;/p&gt;
&lt;p&gt;To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:&lt;/p&gt;
&lt;p&gt;qemu-system-riscv64 -M virt -smp 2 -nographic \
    -kernel arch/riscv/boot/Image \
    -append &amp;#34;percpu_alloc=page&amp;#34;&lt;/p&gt;
&lt;p&gt;Kernel output:&lt;/p&gt;
&lt;p&gt;[    0.000000] Booting Linux on hartid 0
[    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[    0.083192] smp: Bringing up secondary CPUs ...
[    0.086722] ------------[ cut here ]------------
[    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)…&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;riscv: cpu_ops_sbi: Use static array for boot_data&lt;/p&gt;
&lt;p&gt;Since commit 6b9f29b81b15 (&amp;#34;riscv: Enable pcpu page first chunk
allocator&amp;#34;), if NUMA is enabled, the page percpu allocator may be used
on very sparse configurations, or when requested on boot with
percpu_alloc=page.&lt;/p&gt;
&lt;p&gt;In that case, percpu data gets put in the vmalloc area. However,
sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,
and simply assumes that __pa() would work. This causes the just started
hart to immediately access an invalid address and hang.&lt;/p&gt;
&lt;p&gt;Fortunately, struct sbi_hart_boot_data is not too large, so we can
simply allocate an array for boot_data statically, putting it in the
kernel image.&lt;/p&gt;
&lt;p&gt;This fixes NUMA=y SMP boot on Sophgo SG2042.&lt;/p&gt;
&lt;p&gt;To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then
run with:&lt;/p&gt;
&lt;p&gt;qemu-system-riscv64 -M virt -smp 2 -nographic \
    -kernel arch/riscv/boot/Image \
    -append &amp;#34;percpu_alloc=page&amp;#34;&lt;/p&gt;
&lt;p&gt;Kernel output:&lt;/p&gt;
&lt;p&gt;[    0.000000] Booting Linux on hartid 0
[    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025
...
[    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712
...
[    0.083192] smp: Bringing up secondary CPUs ...
[    0.086722] ------------[ cut here ]------------
[    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-qq4v-pr8w-v8hg</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-38407</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38407</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 122 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: riscv: cpu_ops_sbi: Use static array for boot_data Since commit 6b9f29b81b15 (&amp;#34;riscv: Enable pcpu page first chunk allocator&amp;#34;), if NUMA is enabled, the page percpu allocator may be used on very sparse configurations, or when requested on boot with percpu_alloc=page. In that case, percpu data gets put in the vmalloc area. However, sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data, and simply assumes that __pa() would work. This causes the just started hart to immediately access an invalid address and hang. Fortunately, struct sbi_hart_boot_data is not too large, so we can simply allocate an array for boot_data statically, putting it in the kernel image. This fixes NUMA=y SMP boot on Sophgo SG2042. To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then run with:   qemu-system-riscv64 -M virt -smp 2 -nographic \     -kernel arch/riscv/boot/Image \     -append &amp;#34;percpu_alloc=page&amp;#34; Kernel output: [    0.000000] Booting Linux on hartid 0 [    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025 ... [    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712 ... [    0.083192] smp: Bringing up secondary CPUs ... [    0.086722] ------------[ cut here ]------------ [    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080) [    0.0…&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 122 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: riscv: cpu_ops_sbi: Use static array for boot_data Since commit 6b9f29b81b15 (&amp;#34;riscv: Enable pcpu page first chunk allocator&amp;#34;), if NUMA is enabled, the page percpu allocator may be used on very sparse configurations, or when requested on boot with percpu_alloc=page. In that case, percpu data gets put in the vmalloc area. However, sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data, and simply assumes that __pa() would work. This causes the just started hart to immediately access an invalid address and hang. Fortunately, struct sbi_hart_boot_data is not too large, so we can simply allocate an array for boot_data statically, putting it in the kernel image. This fixes NUMA=y SMP boot on Sophgo SG2042. To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then run with:   qemu-system-riscv64 -M virt -smp 2 -nographic \     -kernel arch/riscv/boot/Image \     -append &amp;#34;percpu_alloc=page&amp;#34; Kernel output: [    0.000000] Booting Linux on hartid 0 [    0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025 ... [    0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712 ... [    0.083192] smp: Bringing up secondary CPUs ... [    0.086722] ------------[ cut here ]------------ [    0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080) [    0.0…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38407</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1653 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1653</link>
      <description>&lt;p&gt;Ein entfernter anonymer Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter anonymer Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1653</guid>
    </item>
  </channel>
</rss>
