<?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 08:11:08 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-90047</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-90047</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-90047</guid>
    </item>
    <item>
      <title>EUVD-2026-369535</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-369535</link>
      <description>EUVD-2026-369535</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-369535</guid>
    </item>
    <item>
      <title>fkie_cve-2026-90047</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-90047</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/xe: Don&amp;#39;t hand out the flat CCS storage as usable VRAM&lt;/p&gt;
&lt;p&gt;get_flat_ccs_offset() reads the base of the flat CCS storage from the
hardware, scales it by the number of enabled L3 nodes, and rounds the
result up to 128K.  Everything below that offset is then handed to the
VRAM allocator as usable memory.&lt;/p&gt;
&lt;p&gt;Rounding a limit that means &amp;#34;usable memory ends here&amp;#34; upwards publishes
whatever lies between the real base and the rounded one as free memory,
and that memory belongs to the compression hardware.  The scaled value
has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it
is not:&lt;/p&gt;
&lt;p&gt;flat CCS base: raw 0x3fafff800, rounded 0x3fb000000&lt;/p&gt;
&lt;p&gt;so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&amp;#39;s
pool.  Whatever is allocated there gets that tail overwritten by the
compression hardware, which needs no page-table entry, no buffer object
and no GPU submission to do it, and does it before userspace exists.&lt;/p&gt;
&lt;p&gt;On this machine a Mesa VM&amp;#39;s level-3 page table landed on that page on
every cold boot.  It lost the entry covering the compositor&amp;#39;s
batch-buffer heap, so the compositor&amp;#39;s first submission faulted fetching
its batch and gdm restarted it forever: a black screen on an otherwise
working machine.  Restarting gdm cleared it because the next VM&amp;#39;s page
tables were allocated somewhere else.&lt;/p&gt;
&lt;p&gt;Round down instead, to the page size the allocator works in.  On this
machine that excludes exactly one…&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;drm/xe: Don&amp;#39;t hand out the flat CCS storage as usable VRAM&lt;/p&gt;
&lt;p&gt;get_flat_ccs_offset() reads the base of the flat CCS storage from the
hardware, scales it by the number of enabled L3 nodes, and rounds the
result up to 128K.  Everything below that offset is then handed to the
VRAM allocator as usable memory.&lt;/p&gt;
&lt;p&gt;Rounding a limit that means &amp;#34;usable memory ends here&amp;#34; upwards publishes
whatever lies between the real base and the rounded one as free memory,
and that memory belongs to the compression hardware.  The scaled value
has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it
is not:&lt;/p&gt;
&lt;p&gt;flat CCS base: raw 0x3fafff800, rounded 0x3fb000000&lt;/p&gt;
&lt;p&gt;so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&amp;#39;s
pool.  Whatever is allocated there gets that tail overwritten by the
compression hardware, which needs no page-table entry, no buffer object
and no GPU submission to do it, and does it before userspace exists.&lt;/p&gt;
&lt;p&gt;On this machine a Mesa VM&amp;#39;s level-3 page table landed on that page on
every cold boot.  It lost the entry covering the compositor&amp;#39;s
batch-buffer heap, so the compositor&amp;#39;s first submission faulted fetching
its batch and gdm restarted it forever: a black screen on an otherwise
working machine.  Restarting gdm cleared it because the next VM&amp;#39;s page
tables were allocated somewhere else.&lt;/p&gt;
&lt;p&gt;Round down instead, to the page size the allocator works in.  On this
machine that excludes exactly one…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-90047</guid>
    </item>
    <item>
      <title>GHSA-wrw4-jww2-vw64</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-wrw4-jww2-vw64</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;drm/xe: Don&amp;#39;t hand out the flat CCS storage as usable VRAM&lt;/p&gt;
&lt;p&gt;get_flat_ccs_offset() reads the base of the flat CCS storage from the
hardware, scales it by the number of enabled L3 nodes, and rounds the
result up to 128K.  Everything below that offset is then handed to the
VRAM allocator as usable memory.&lt;/p&gt;
&lt;p&gt;Rounding a limit that means &amp;#34;usable memory ends here&amp;#34; upwards publishes
whatever lies between the real base and the rounded one as free memory,
and that memory belongs to the compression hardware.  The scaled value
has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it
is not:&lt;/p&gt;
&lt;p&gt;flat CCS base: raw 0x3fafff800, rounded 0x3fb000000&lt;/p&gt;
&lt;p&gt;so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&amp;#39;s
pool.  Whatever is allocated there gets that tail overwritten by the
compression hardware, which needs no page-table entry, no buffer object
and no GPU submission to do it, and does it before userspace exists.&lt;/p&gt;
&lt;p&gt;On this machine a Mesa VM&amp;#39;s level-3 page table landed on that page on
every cold boot.  It lost the entry covering the compositor&amp;#39;s
batch-buffer heap, so the compositor&amp;#39;s first submission faulted fetching
its batch and gdm restarted it forever: a black screen on an otherwise
working machine.  Restarting gdm cleared it because the next VM&amp;#39;s page
tables were allocated somewhere else.&lt;/p&gt;
&lt;p&gt;Round down instead, to the page size the allocator works in.  On this
machine that excludes exactly one…&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;drm/xe: Don&amp;#39;t hand out the flat CCS storage as usable VRAM&lt;/p&gt;
&lt;p&gt;get_flat_ccs_offset() reads the base of the flat CCS storage from the
hardware, scales it by the number of enabled L3 nodes, and rounds the
result up to 128K.  Everything below that offset is then handed to the
VRAM allocator as usable memory.&lt;/p&gt;
&lt;p&gt;Rounding a limit that means &amp;#34;usable memory ends here&amp;#34; upwards publishes
whatever lies between the real base and the rounded one as free memory,
and that memory belongs to the compression hardware.  The scaled value
has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it
is not:&lt;/p&gt;
&lt;p&gt;flat CCS base: raw 0x3fafff800, rounded 0x3fb000000&lt;/p&gt;
&lt;p&gt;so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&amp;#39;s
pool.  Whatever is allocated there gets that tail overwritten by the
compression hardware, which needs no page-table entry, no buffer object
and no GPU submission to do it, and does it before userspace exists.&lt;/p&gt;
&lt;p&gt;On this machine a Mesa VM&amp;#39;s level-3 page table landed on that page on
every cold boot.  It lost the entry covering the compositor&amp;#39;s
batch-buffer heap, so the compositor&amp;#39;s first submission faulted fetching
its batch and gdm restarted it forever: a black screen on an otherwise
working machine.  Restarting gdm cleared it because the next VM&amp;#39;s page
tables were allocated somewhere else.&lt;/p&gt;
&lt;p&gt;Round down instead, to the page size the allocator works in.  On this
machine that excludes exactly one…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-wrw4-jww2-vw64</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-90047</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-90047</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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don&amp;#39;t hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K.  Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means &amp;#34;usable memory ends here&amp;#34; upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware.  The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: 	flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&amp;#39;s pool.  Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM&amp;#39;s level-3 page table landed on that page on every cold boot.  It lost the entry covering the compositor&amp;#39;s batch-buffer heap, so the compositor&amp;#39;s first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine.  Restarting gdm cleared it because the next VM&amp;#39;s page tables were allocated somewhere else. Round down instead, to the page size the allocator works in.  On this machine that excludes exactly one page. R…&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 120 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: drm/xe: Don&amp;#39;t hand out the flat CCS storage as usable VRAM get_flat_ccs_offset() reads the base of the flat CCS storage from the hardware, scales it by the number of enabled L3 nodes, and rounds the result up to 128K.  Everything below that offset is then handed to the VRAM allocator as usable memory. Rounding a limit that means &amp;#34;usable memory ends here&amp;#34; upwards publishes whatever lies between the real base and the rounded one as free memory, and that memory belongs to the compression hardware.  The scaled value has no reason to be 128K aligned, and on a Battlemage G21 with 16 GiB it is not: 	flat CCS base: raw 0x3fafff800, rounded 0x3fb000000 so the last 2 KiB of page 0x3fafff000 is CCS storage, in the allocator&amp;#39;s pool.  Whatever is allocated there gets that tail overwritten by the compression hardware, which needs no page-table entry, no buffer object and no GPU submission to do it, and does it before userspace exists. On this machine a Mesa VM&amp;#39;s level-3 page table landed on that page on every cold boot.  It lost the entry covering the compositor&amp;#39;s batch-buffer heap, so the compositor&amp;#39;s first submission faulted fetching its batch and gdm restarted it forever: a black screen on an otherwise working machine.  Restarting gdm cleared it because the next VM&amp;#39;s page tables were allocated somewhere else. Round down instead, to the page size the allocator works in.  On this machine that excludes exactly one page. R…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-90047</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3438 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3438</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen oder eine nicht näher spezifizierte Auswirkung zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service zu verursachen oder eine nicht näher spezifizierte Auswirkung zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3438</guid>
    </item>
  </channel>
</rss>
