<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T19:30:17.907689+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-93201</id>
    <title>BELL-CVE-2026-93201</title>
    <updated>2026-10-02T19:30:18.029055+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-93201"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-372221</id>
    <title>EUVD-2026-372221</title>
    <updated>2026-10-02T19:30:18.029104+00:00</updated>
    <content>EUVD-2026-372221</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-372221"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-93201</id>
    <title>fkie_cve-2026-93201</title>
    <updated>2026-10-02T19:30:18.029120+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>dm-pcache: validate seg_id fields from persistent memory</p>
<p>cache_pos_decode(), cache_key_decode() and the last-kset branches of
cache_replay(), the writeback worker and the GC worker take a cache
segment id from the cache device metadata and index cache-&gt;segments[]
with it without checking it against cache-&gt;n_segs. That metadata is only
CRC-protected with a fixed public seed, so whoever supplies the cache
device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range
value forms a wild pcache_cache_segment pointer that is dereferenced and
written through -- an out-of-bounds read and write driven by on-disk data.</p>
<p>Add cache_seg_id_valid() and reject an out-of-range id at each decode
site, failing the operation with -EIO instead of indexing past the array.
Bound the id against the initialized-segment count (cache_info.n_segs)
rather than the physical device total. A forged cache_info.n_segs below
seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed
structs whose data pointer is NULL, so a forged id in that window would
still be dereferenced. A later patch guarantees cache_info.n_segs &lt;=
seg_num, and a driver-created cache sets the two equal, so valid images
are unaffected.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-93201"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-rr92-7pj4-8whf</id>
    <title>GHSA-rr92-7pj4-8whf</title>
    <updated>2026-10-02T19:30:18.029158+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>dm-pcache: validate seg_id fields from persistent memory</p>
<p>cache_pos_decode(), cache_key_decode() and the last-kset branches of
cache_replay(), the writeback worker and the GC worker take a cache
segment id from the cache device metadata and index cache-&gt;segments[]
with it without checking it against cache-&gt;n_segs. That metadata is only
CRC-protected with a fixed public seed, so whoever supplies the cache
device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range
value forms a wild pcache_cache_segment pointer that is dereferenced and
written through -- an out-of-bounds read and write driven by on-disk data.</p>
<p>Add cache_seg_id_valid() and reject an out-of-range id at each decode
site, failing the operation with -EIO instead of indexing past the array.
Bound the id against the initialized-segment count (cache_info.n_segs)
rather than the physical device total. A forged cache_info.n_segs below
seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed
structs whose data pointer is NULL, so a forged id in that window would
still be dereferenced. A later patch guarantees cache_info.n_segs &lt;=
seg_num, and a driver-created cache sets the two equal, so valid images
are unaffected.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-rr92-7pj4-8whf"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1</id>
    <title>openSUSE-SU-2026:11880-1 — kernel-devel-7.2.7-1.1 on GA media</title>
    <updated>2026-10-02T19:30:18.029185+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-7.2.7-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:11880-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-93201</id>
    <title>UBUNTU-CVE-2026-93201</title>
    <updated>2026-10-02T19:30:18.029736+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 118 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: dm-pcache: validate seg_id fields from persistent memory cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache-&gt;segments[] with it without checking it against cache-&gt;n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs &lt;= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-93201"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3444</id>
    <title>WID-SEC-W-2026-3444 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-02T19:30:18.030001+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel möglicherweise ausnutzen, um Berechtigungen zu erweitern, Sicherheitsmaßnahmen zu umgehen, Daten offenzulegen oder zu manipulieren, den Speicher zu beschädigen, Denial-of-Service-Zustände zu verursachen oder andere, nicht näher spezifizierte Angriffe durchzuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3444"/>
  </entry>
</feed>
