CVE-2026-99220

What it actually does

Unconditional dereference of a NULL asym_key_ids slot left empty by the PKCS#8 parser inside key_or_keyring_common, resulting in a kernel NULL pointer dereference and panic when an unprivileged process invokes KEYCTL_RESTRICT_KEYRING followed by add_key.

Why it matters to the business

Local denial-of-service that crashes the entire system; any unprivileged account can trigger a kernel panic, halting all workloads until reboot and potentially disrupting availability of services running on the host.

How an attack unfolds

An attacker with local unprivileged access supplies a PKCS#8 private key to a key_or_keyring restriction via the keyctl syscall, then calls add_key; both plain and :chain restriction forms reach the unconditional dereference in key_or_keyring_common, causing an immediate general protection fault and kernel panic.

How to fix it

Apply the upstream fix that rejects asymmetric restriction keys lacking key IDs before they reach key_or_keyring_common; rebuild and deploy the patched kernel across all affected distributions; until patches are available, restrict unprivileged use of KEYCTL_RESTRICT_KEYRING via LSM or seccomp filters where feasible.

How to confirm the fix worked

Confirm the patched kernel contains the check that returns an error for PKCS#8 keys without IDs in key_or_keyring_common; attempt the original KEYCTL_RESTRICT_KEYRING + add_key sequence from an unprivileged context and verify it now fails safely instead of dereferencing NULL.

Typical attack path

1. Obtain local unprivileged shell or process on the target Linux system
2. Craft or load a PKCS#8-formatted asymmetric key without key IDs
3. Invoke KEYCTL_RESTRICT_KEYRING on the key (plain or :chain form)
4. Call add_key to trigger the NULL dereference path
5. Observe kernel oops and panic

How to detect it

Search kernel logs (dmesg, journalctl, /var/log/kern.log) for the signature strings from the oops: 'key_or_keyring_common', 'general protection fault', 'null-ptr-deref', and the call trace involving __key_create_or_update and __do_sys_add_key.

• key_or_keyring_common (crypto/asymmetric_keys/restrict.c
• KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
• RIP: 0010:key_or_keyring_common
• Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000
• __do_sys_add_key (security/keys/keyctl.c:134)

What your security team should do

• Immediately schedule kernel updates for all Linux hosts once fixed packages are released
• Audit systems for any custom key-restriction workflows that might rely on PKCS#8 trust anchors
• Consider temporary seccomp or LSM policies blocking KEYCTL_RESTRICT_KEYRING for untrusted users until patched
• Monitor for kernel oops reports containing key_or_keyring_common in the call stack