<?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>Thu, 15 Oct 2026 20:58:12 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-38407 — riscv: cpu_ops_sbi: Use static array for boot_data</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-38407</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&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;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&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/cve-2025-38407</guid>
    </item>
    <item>
      <title>USN-7833-1 — linux, linux-aws, linux-gcp, linux-oem-6.14, linux-oracle, linux-oracle-6.14, linux-raspi, linux-realtime vulnerabiliti…</title>
      <link>https://cve.radiocsirt.org/vuln/usn-7833-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-oem-6.14, Ubuntu:24.04:LTS: linux-oracle-6.14&lt;/p&gt;
&lt;p&gt;Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos,
and Flavien Solt discovered that some AMD processors may allow an attacker
to infer data from previous stores, potentially resulting in the leakage of
privileged information. A local attacker could possibly use this to expose
sensitive information. (CVE-2024-36350, CVE-2024-36357)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - ACPI drivers;
  - Serial ATA and Parallel ATA drivers;
  - Drivers core;
  - ATA over ethernet (AOE) driver;
  - Ublk userspace block driver;
  - Bus devices;
  - DMA engine subsystem;
  - Arm Firmware Framework for ARMv8-A(FFA);
  - Cirrus firmware drivers;
  - GPU drivers;
  - HID subsystem;
  - Hardware monitoring drivers;
  - I2C subsystem;
  - InfiniBand drivers;
  - Input Device (Miscellaneous) drivers;
  - Multiple devices driver;
  - Media drivers;
  - TI TPS6594 PFSM driver;
  - MMC subsystem;
  - MTD block device drivers;
  - Network drivers;
  - NVME drivers;
  - x86 platform drivers;
  - RapidIO drivers;
  - Voltage and Current Regulator drivers;
  - Remote Processor subsystem;
  - S/390 drivers;
  - SCSI subsystem;
  - TCM subsystem;
  - Trusted Execution Environment drivers;
  - TTY drivers;
  - ChipIdea USB dr…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-oem-6.14, Ubuntu:24.04:LTS: linux-oracle-6.14&lt;/p&gt;
&lt;p&gt;Oleksii Oleksenko, Cedric Fournet, Jana Hofmann, Boris Köpf, Stavros Volos,
and Flavien Solt discovered that some AMD processors may allow an attacker
to infer data from previous stores, potentially resulting in the leakage of
privileged information. A local attacker could possibly use this to expose
sensitive information. (CVE-2024-36350, CVE-2024-36357)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - x86 architecture;
  - ACPI drivers;
  - Serial ATA and Parallel ATA drivers;
  - Drivers core;
  - ATA over ethernet (AOE) driver;
  - Ublk userspace block driver;
  - Bus devices;
  - DMA engine subsystem;
  - Arm Firmware Framework for ARMv8-A(FFA);
  - Cirrus firmware drivers;
  - GPU drivers;
  - HID subsystem;
  - Hardware monitoring drivers;
  - I2C subsystem;
  - InfiniBand drivers;
  - Input Device (Miscellaneous) drivers;
  - Multiple devices driver;
  - Media drivers;
  - TI TPS6594 PFSM driver;
  - MMC subsystem;
  - MTD block device drivers;
  - Network drivers;
  - NVME drivers;
  - x86 platform drivers;
  - RapidIO drivers;
  - Voltage and Current Regulator drivers;
  - Remote Processor subsystem;
  - S/390 drivers;
  - SCSI subsystem;
  - TCM subsystem;
  - Trusted Execution Environment drivers;
  - TTY drivers;
  - ChipIdea USB dr…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-7833-1</guid>
    </item>
  </channel>
</rss>
