GHSA-9PJV-MG4C-3J9M

Vulnerability from github – Published: 2026-11-02 18:32 – Updated: 2026-11-03 21:32
VLAI
Details

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->user->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->sem)
  load old keyring->user
                                     replace key->user and key->uid
                                     up_write(key->sem)
                                     key_put(key)
                                     key_user_put(old user): free
  read old user->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->uid for the mapping check. key_alloc() initializes this inline owner UID and keyctl_chown_key() updates it on chown. The existing name lock keeps its containing keyring allocated throughout the check, so lookup no longer depends on the account's lifetime. This also matches the owner UID used by the permission check.

KASAN report as below:

BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0
Read of size 4 at addr ffff8881128ae2ec by task keycase/500
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-99226"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-11-02T16:17:47Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nkeys: Avoid the owner account dereference in named keyring lookup\n\nNamed keyring lookup must keep the storage containing the owner UID\nalive through the namespace mapping check.  find_keyring_by_name()\nreads keyring-\u003euser-\u003euid under keyring_name_lock, but that lock protects\nthe keyring\u0027s name entry and allocation, not its separate key_user.\n\nA named session-keyring join can overlap a privileged KEYCTL_CHOWN on\nanother CPU.  If the keyring holds the last reference to its old dynamic\nkey_user and the ownership transfer succeeds, the following ordering is\npossible:\n\n    Named join                         Chown\n    find_keyring_by_name()              keyctl_chown_key()\n      read_lock(keyring_name_lock)       down_write(key-\u003esem)\n      load old keyring-\u003euser\n                                         replace key-\u003euser and key-\u003euid\n                                         up_write(key-\u003esem)\n                                         key_put(key)\n                                         key_user_put(old user): free\n      read old user-\u003euid\n      read_unlock(keyring_name_lock)\n\nChown neither takes keyring_name_lock nor key_session_mutex, so it can\nfree the old account between the pointer load and the UID read.  The\nlookup then reads freed memory even though the keyring itself is alive.\n\nUse keyring-\u003euid for the mapping check.  key_alloc() initializes this\ninline owner UID and keyctl_chown_key() updates it on chown.\nThe existing name lock keeps its containing keyring allocated throughout\nthe check, so lookup no longer depends on the account\u0027s lifetime.  This\nalso matches the owner UID used by the permission check.\n\nKASAN report as below:\n\n    BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0\n    Read of size 4 at addr ffff8881128ae2ec by task keycase/500",
  "id": "GHSA-9pjv-mg4c-3j9m",
  "modified": "2026-11-03T21:32:00Z",
  "published": "2026-11-02T18:32:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99226"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0b865fa477d94ac96c26848aab1fd176397de3f6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/40b12b93ae4ab9e22c3d571e9b09fd08afad53f6"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/51409aaa01f8602552c336009fd22b226b0cdf1d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5c6a9512887a6cc694d594d9c0b57c0841d215b5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6763329f673d261641c79212abf773af77b2c922"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/77249d4b1bb5ad43552b7023c4a0978937aa7a56"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/aa03c8fb4334f14d218020f7431debf2b7766865"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b0830a26e2c3008a6e21863126b4a0e68b2761cd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c9664f780f861dd9f11f120c7a03ed0993671ebb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.