<?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 12:26:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-38334 — x86/sgx: Prevent attempts to reclaim poisoned pages</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-38334</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;x86/sgx: Prevent attempts to reclaim poisoned pages&lt;/p&gt;
&lt;p&gt;TL;DR: SGX page reclaim touches the page to copy its contents to
secondary storage. SGX instructions do not gracefully handle machine
checks. Despite this, the existing SGX code will try to reclaim pages
that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.&lt;/p&gt;
&lt;p&gt;The longer story:&lt;/p&gt;
&lt;p&gt;Pages used by an enclave only get epc_page-&amp;gt;poison set in
arch_memory_failure() but they currently stay on sgx_active_page_list until
sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.&lt;/p&gt;
&lt;p&gt;epc_page-&amp;gt;poison is not checked in the reclaimer logic meaning that, if other
conditions are met, an attempt will be made to reclaim an EPC page that was
poisoned.  This is bad because 1. we don&amp;#39;t want that page to end up added
to another enclave and 2. it is likely to cause one core to shut down
and the kernel to panic.&lt;/p&gt;
&lt;p&gt;Specifically, reclaiming uses microcode operations including &amp;#34;EWB&amp;#34; which
accesses the EPC page contents to encrypt and write them out to non-SGX
memory.  Those operations cannot handle MCEs in their accesses other than
by putting the executing core into a special shutdown state (affecting
both threads with HT.)  The kernel will subsequently panic on the
remaining cores seeing the core didn&amp;#39;t enter MCE handler(s) in time.&lt;/p&gt;
&lt;p&gt;Call sgx_unmark_page_reclaimable() to remove the affected EPC page from
sgx_active_page_list on memory error to stop…&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;x86/sgx: Prevent attempts to reclaim poisoned pages&lt;/p&gt;
&lt;p&gt;TL;DR: SGX page reclaim touches the page to copy its contents to
secondary storage. SGX instructions do not gracefully handle machine
checks. Despite this, the existing SGX code will try to reclaim pages
that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.&lt;/p&gt;
&lt;p&gt;The longer story:&lt;/p&gt;
&lt;p&gt;Pages used by an enclave only get epc_page-&amp;gt;poison set in
arch_memory_failure() but they currently stay on sgx_active_page_list until
sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.&lt;/p&gt;
&lt;p&gt;epc_page-&amp;gt;poison is not checked in the reclaimer logic meaning that, if other
conditions are met, an attempt will be made to reclaim an EPC page that was
poisoned.  This is bad because 1. we don&amp;#39;t want that page to end up added
to another enclave and 2. it is likely to cause one core to shut down
and the kernel to panic.&lt;/p&gt;
&lt;p&gt;Specifically, reclaiming uses microcode operations including &amp;#34;EWB&amp;#34; which
accesses the EPC page contents to encrypt and write them out to non-SGX
memory.  Those operations cannot handle MCEs in their accesses other than
by putting the executing core into a special shutdown state (affecting
both threads with HT.)  The kernel will subsequently panic on the
remaining cores seeing the core didn&amp;#39;t enter MCE handler(s) in time.&lt;/p&gt;
&lt;p&gt;Call sgx_unmark_page_reclaimable() to remove the affected EPC page from
sgx_active_page_list on memory error to stop…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-38334</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>
