<?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>Sat, 03 Oct 2026 17:52:41 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-16150</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-16150</link>
      <description>bdu:2025-16150</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-16150</guid>
    </item>
    <item>
      <title>BELL-CVE-2025-40181</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2025-40181</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-40181</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0169 — 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-2026-avi-0169</link>
      <description>certfr-2026-avi-0169</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0169</guid>
    </item>
    <item>
      <title>EUVD-2026-314945</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-314945</link>
      <description>EUVD-2026-314945</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-314945</guid>
    </item>
    <item>
      <title>fkie_cve-2025-40181</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-40181</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP&lt;/p&gt;
&lt;p&gt;When running as an SNP or TDX guest under KVM, force the legacy PCI hole,
i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC
via a forced variable MTRR range.&lt;/p&gt;
&lt;p&gt;In most KVM-based setups, legacy devices such as the HPET and TPM are
enumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and
optionally a SystemMemory descriptor for an OperationRegion, e.g. if the
device needs to be accessed via a Control Method.&lt;/p&gt;
&lt;p&gt;If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will
auto-ioremap the region so that it can be accessed at will.  However, the
ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of
SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region
must be mapped as UC vs. WB, etc.  As a result, Linux&amp;#39;s ACPI driver always
maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.&lt;/p&gt;
&lt;p&gt;The dedicated device drivers however, e.g. the HPET driver and TPM driver,
want to map their associated memory as UC or WC, as accessing PCI devices
using WB is unsupported.&lt;/p&gt;
&lt;p&gt;On bare metal and non-CoCO, the conflicting requirements &amp;#34;work&amp;#34; as firmware
configures the PCI hole (and other device memory) to be UC in the MTRRs.
So even though the ACPI mappings request WB, they are forced to UC- in the
kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides,
and thu…&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;x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP&lt;/p&gt;
&lt;p&gt;When running as an SNP or TDX guest under KVM, force the legacy PCI hole,
i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC
via a forced variable MTRR range.&lt;/p&gt;
&lt;p&gt;In most KVM-based setups, legacy devices such as the HPET and TPM are
enumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and
optionally a SystemMemory descriptor for an OperationRegion, e.g. if the
device needs to be accessed via a Control Method.&lt;/p&gt;
&lt;p&gt;If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will
auto-ioremap the region so that it can be accessed at will.  However, the
ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of
SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region
must be mapped as UC vs. WB, etc.  As a result, Linux&amp;#39;s ACPI driver always
maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.&lt;/p&gt;
&lt;p&gt;The dedicated device drivers however, e.g. the HPET driver and TPM driver,
want to map their associated memory as UC or WC, as accessing PCI devices
using WB is unsupported.&lt;/p&gt;
&lt;p&gt;On bare metal and non-CoCO, the conflicting requirements &amp;#34;work&amp;#34; as firmware
configures the PCI hole (and other device memory) to be UC in the MTRRs.
So even though the ACPI mappings request WB, they are forced to UC- in the
kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides,
and thu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-40181</guid>
    </item>
    <item>
      <title>GHSA-x7gh-c69c-j2v8</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-x7gh-c69c-j2v8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP&lt;/p&gt;
&lt;p&gt;When running as an SNP or TDX guest under KVM, force the legacy PCI hole,
i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC
via a forced variable MTRR range.&lt;/p&gt;
&lt;p&gt;In most KVM-based setups, legacy devices such as the HPET and TPM are
enumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and
optionally a SystemMemory descriptor for an OperationRegion, e.g. if the
device needs to be accessed via a Control Method.&lt;/p&gt;
&lt;p&gt;If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will
auto-ioremap the region so that it can be accessed at will.  However, the
ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of
SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region
must be mapped as UC vs. WB, etc.  As a result, Linux&amp;#39;s ACPI driver always
maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.&lt;/p&gt;
&lt;p&gt;The dedicated device drivers however, e.g. the HPET driver and TPM driver,
want to map their associated memory as UC or WC, as accessing PCI devices
using WB is unsupported.&lt;/p&gt;
&lt;p&gt;On bare metal and non-CoCO, the conflicting requirements &amp;#34;work&amp;#34; as firmware
configures the PCI hole (and other device memory) to be UC in the MTRRs.
So even though the ACPI mappings request WB, they are forced to UC- in the
kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides,
and thu…&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;x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP&lt;/p&gt;
&lt;p&gt;When running as an SNP or TDX guest under KVM, force the legacy PCI hole,
i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC
via a forced variable MTRR range.&lt;/p&gt;
&lt;p&gt;In most KVM-based setups, legacy devices such as the HPET and TPM are
enumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and
optionally a SystemMemory descriptor for an OperationRegion, e.g. if the
device needs to be accessed via a Control Method.&lt;/p&gt;
&lt;p&gt;If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will
auto-ioremap the region so that it can be accessed at will.  However, the
ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of
SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region
must be mapped as UC vs. WB, etc.  As a result, Linux&amp;#39;s ACPI driver always
maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.&lt;/p&gt;
&lt;p&gt;The dedicated device drivers however, e.g. the HPET driver and TPM driver,
want to map their associated memory as UC or WC, as accessing PCI devices
using WB is unsupported.&lt;/p&gt;
&lt;p&gt;On bare metal and non-CoCO, the conflicting requirements &amp;#34;work&amp;#34; as firmware
configures the PCI hole (and other device memory) to be UC in the MTRRs.
So even though the ACPI mappings request WB, they are forced to UC- in the
kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides,
and thu…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-x7gh-c69c-j2v8</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20826-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-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/opensuse-su-2026:20826-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0587-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0587-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-2026:0587-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2025-40181</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40181</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 100 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an SNP or TDX guest under KVM, force the legacy PCI hole, i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC via a forced variable MTRR range. In most KVM-based setups, legacy devices such as the HPET and TPM are enumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and optionally a SystemMemory descriptor for an OperationRegion, e.g. if the device needs to be accessed via a Control Method. If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will auto-ioremap the region so that it can be accessed at will.  However, the ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region must be mapped as UC vs. WB, etc.  As a result, Linux&amp;#39;s ACPI driver always maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their associated memory as UC or WC, as accessing PCI devices using WB is unsupported. On bare metal and non-CoCO, the conflicting requirements &amp;#34;work&amp;#34; as firmware configures the PCI hole (and other device memory) to be UC in the MTRRs. So even though the ACPI mappings request WB, they are forced to UC- in the kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides, and thus are…&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 100 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP When running as an SNP or TDX guest under KVM, force the legacy PCI hole, i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC via a forced variable MTRR range. In most KVM-based setups, legacy devices such as the HPET and TPM are enumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and optionally a SystemMemory descriptor for an OperationRegion, e.g. if the device needs to be accessed via a Control Method. If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will auto-ioremap the region so that it can be accessed at will.  However, the ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region must be mapped as UC vs. WB, etc.  As a result, Linux&amp;#39;s ACPI driver always maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86. The dedicated device drivers however, e.g. the HPET driver and TPM driver, want to map their associated memory as UC or WC, as accessing PCI devices using WB is unsupported. On bare metal and non-CoCO, the conflicting requirements &amp;#34;work&amp;#34; as firmware configures the PCI hole (and other device memory) to be UC in the MTRRs. So even though the ACPI mappings request WB, they are forced to UC- in the kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides, and thus are…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-40181</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2595 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2595</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2595</guid>
    </item>
  </channel>
</rss>
