<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-05T04:17:27.638990+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/fkie_cve-2026-99226</id>
    <title>fkie_cve-2026-99226</title>
    <updated>2026-11-05T04:17:27.646506+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>keys: Avoid the owner account dereference in named keyring lookup</p>
<p>Named keyring lookup must keep the storage containing the owner UID
alive through the namespace mapping check.  find_keyring_by_name()
reads keyring-&gt;user-&gt;uid under keyring_name_lock, but that lock protects
the keyring's name entry and allocation, not its separate key_user.</p>
<p>A named session-keyring join can overlap a privileged KEYCTL_CHOWN on
another CPU.  If the keyring holds the last reference to its old dynamic
key_user and the ownership transfer succeeds, the following ordering is
possible:</p>
<p>Named join                         Chown
    find_keyring_by_name()              keyctl_chown_key()
      read_lock(keyring_name_lock)       down_write(key-&gt;sem)
      load old keyring-&gt;user
                                         replace key-&gt;user and key-&gt;uid
                                         up_write(key-&gt;sem)
                                         key_put(key)
                                         key_user_put(old user): free
      read old user-&gt;uid
      read_unlock(keyring_name_lock)</p>
<p>Chown neither takes keyring_name_lock nor key_session_mutex, so it can
free the old account between the pointer load and the UID read.  The
lookup then reads freed memory even though the keyring itself is alive.</p>
<p>Use keyring-&gt;uid for the mapping check.  key_alloc() initializes this
inline owner UID and keyctl_chown_key() updates it on chown.
Th…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-99226"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-9pjv-mg4c-3j9m</id>
    <title>GHSA-9pjv-mg4c-3j9m</title>
    <updated>2026-11-05T04:17:27.646631+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>keys: Avoid the owner account dereference in named keyring lookup</p>
<p>Named keyring lookup must keep the storage containing the owner UID
alive through the namespace mapping check.  find_keyring_by_name()
reads keyring-&gt;user-&gt;uid under keyring_name_lock, but that lock protects
the keyring's name entry and allocation, not its separate key_user.</p>
<p>A named session-keyring join can overlap a privileged KEYCTL_CHOWN on
another CPU.  If the keyring holds the last reference to its old dynamic
key_user and the ownership transfer succeeds, the following ordering is
possible:</p>
<p>Named join                         Chown
    find_keyring_by_name()              keyctl_chown_key()
      read_lock(keyring_name_lock)       down_write(key-&gt;sem)
      load old keyring-&gt;user
                                         replace key-&gt;user and key-&gt;uid
                                         up_write(key-&gt;sem)
                                         key_put(key)
                                         key_user_put(old user): free
      read old user-&gt;uid
      read_unlock(keyring_name_lock)</p>
<p>Chown neither takes keyring_name_lock nor key_session_mutex, so it can
free the old account between the pointer load and the UID read.  The
lookup then reads freed memory even though the keyring itself is alive.</p>
<p>Use keyring-&gt;uid for the mapping check.  key_alloc() initializes this
inline owner UID and keyctl_chown_key() updates it on chown.
Th…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-9pjv-mg4c-3j9m"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-99226</id>
    <title>UBUNTU-CVE-2026-99226</title>
    <updated>2026-11-05T04:17:27.646669+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 257 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: keys: Avoid the owner account dereference in named keyring lookup Named keyring lookup must keep the storage containing the owner UID alive through the namespace mapping check.  find_keyring_by_name() reads keyring-&gt;user-&gt;uid under keyring_name_lock, but that lock protects the keyring's name entry and allocation, not its separate key_user. A named session-keyring join can overlap a privileged KEYCTL_CHOWN on another CPU.  If the keyring holds the last reference to its old dynamic key_user and the ownership transfer succeeds, the following ordering is possible:     Named join                         Chown     find_keyring_by_name()              keyctl_chown_key()       read_lock(keyring_name_lock)       down_write(key-&gt;sem)       load old keyring-&gt;user                                          replace key-&gt;user and key-&gt;uid                                          up_write(key-&gt;sem)                                          key_put(key)                                          key_user_put(old user): free       read old user-&gt;uid       read_unlock(keyring_name_lock) Chown neither takes keyring_name_lock nor key_session_mutex, so it can free the old account between the pointer load and the UID read.  The lookup then reads freed memory even though the keyring itself is alive. Use keyring-&gt;uid for the mapping check.  key_alloc() initializes this inline owner UID and keyctl_chown_key() updates it on chown. The exis…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-99226"/>
  </entry>
</feed>
