---
id: "CVE-2026-99220"
kind: "vulnerability"
aliases: ["CVE-2026-99220"]
title: "Linux kernel: keyring restriction crash lets an unprivileged user panic the system"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["kernel", "linux", "multi-tenant", "runtime", "self-hosted"]
not_affected_if: ["kernel-patched", "no-untrusted-local-users"]
published_at: "2026-11-02T16:17:46+00:00"
first_seen_at: "2026-11-02T16:24:05+00:00"
updated_at: "2026-11-02T16:29:39+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99220", "first_seen_at": "2026-11-02T16:24:05+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-11-02T16:29:39+00:00"}]
---

# Linux kernel: keyring restriction crash lets an unprivileged user panic the system

A flaw in the Linux kernel's asymmetric key handling lets a local user supply a PKCS#8 key to a key-ring restriction and trigger a NULL pointer dereference. The result is a kernel crash (panic) on the machine.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `uname -r` and check your distribution's kernel changelog or tracker for CVE-2026-99220 or the commit 9695df3b1db4 (stable 2a40bdd44095).
- Exposure needs a kernel with the PKCS#8 key parser (the Fixes target is 3c58b2362ba8; check `grep PKCS8 /boot/config-$(uname -r)` for CONFIG_PKCS8_PRIVATE_KEY_PARSER) and local users who can call add_key and keyctl restrict_keyring, which is the default on most systems.
- Also check shared hosts, CI runners and container hosts where untrusted code runs, since containers share the host kernel.

## Fix

Upstream fix: commit 9695df3b1db4ac4534274d38ee16e3b9b0bf910e (asymmetric_keys: reject trust keys without IDs, applied by Herbert Xu). A stable backport, commit 2a40bdd4409567de4c2a141ac66439dc238af752, was committed by Greg Kroah-Hartman on 2026-10-30. The stable point release that contains it is not confirmed in the sources read; take a kernel from your distribution that lists CVE-2026-99220 or this commit as fixed.

## Timeline

- 2026-11-02T16:24:05+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99220
- 2026-11-02T16:29:39+00:00 analyst — Read the patch v3 thread (Herbert Xu: applied) and the linux-stable commit; upstream commit 9695df3b1db4, stable backport 2a40bdd44095 dated 2026-10-30. Per-branch fixed versions not found in sources; left unknown, nothing marked verified. NVD page returned nothing via web-cli. No exploitation observed.

## Documents

- [advisory] [PATCH v3] asymmetric_keys: reject trust keys without IDs (patch + Herbert Xu 'Patch applied') https://lore.landau.one/lkml/20260906110152.240426-2-bestswngs@gmail.com/T/
- [fix] linux-stable commit 2a40bdd44095: asymmetric_keys: reject trust keys without IDs (upstream 9695df3b1db4) https://repo.or.cz/linux-stable.git/commit/2a40bdd4409567de4c2a141ac66439dc238af752

## From the sources

In the Linux kernel, the following vulnerability has been resolved:

asymmetric_keys: reject trust keys without IDs

The PKCS#8 parser deliberately leaves the asym_key_ids payload slot
empty. key_or_keyring_common() unconditionally dereferences that slot
when a PKCS#8 key is supplied to a key_or_keyring restriction. Both the
plain and :chain forms reach this branch, allowing an unprivileged caller
to trigger a NULL pointer dereference through KEYCTL_RESTRICT_KEYRING
followed by add_key().

 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000
 KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
 RIP: 0010:key_or_keyring_common (crypto/asymmetric_keys/restrict.c:205 crypto/asymmetric_keys/restrict.c:279)
 Call Trace:
  <TASK>
  __key_create_or_update (security/keys/key.c:884)
  key_create_or_update (security/keys/key.c:1021)
  __do_sys_add_key (security/keys/keyctl.c:134)
  do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
  </TASK>
 Kernel panic - not syncing: Fatal exception

Reject an asymmetric restriction key without key IDs. A PKCS#8 private
key cannot identify the signer of a candidate certificate and is not a
valid trust anchor.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_