asymmetric_keys: reject trust keys without IDs
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. A PKCS#8 key is supplied to a key_or_keyring restriction (plain or :chain form)
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 30/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Linux kernel's asymmetric keys subsystem, specifically the key_or_keyring restriction logic used with keyrings, is affected. A local, unprivileged user can crash the system with a NULL pointer dereference by supplying a PKCS#8 key to a restricted keyring, causing a kernel panic.
Read the original description
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.
What to do
Check whether your setup matches what the bug needs.
A PKCS#8 key is supplied to a key_or_keyring restriction (plain or :chain form)Workaround: The checked facts give no workaround. Until a fix is available, the affected feature can be limited by avoiding supplying PKCS#8 keys to key_or_keyring restrictions through KEYCTL_RESTRICT_KEYRING.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
4.20
Evidence 6
- Link
- Link
- Link
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-99220
What does this mean?
An unprivileged caller can trigger a kernel NULL pointer dereference through KEYCTL_RESTRICT_KEYRING, which causes a kernel panic and a denial of service. The bug occurs when a PKCS#8 key is supplied to a key_or_keyring restriction, in either the plain or :chain form.Source: git.kernel.org
Am I affected, and how do I check?
The checked facts list only the Linux kernel and give no version ranges. The setup in question is use of KEYCTL_RESTRICT_KEYRING with a PKCS#8 key supplied to a key_or_keyring restriction, plain or :chain. To check a system, compare its kernel version with the affected versions in the kernel advisory, which the checked facts do not include.Source: git.kernel.org
What should I do about it?
The checked facts do not name a fixed kernel version or an upgrade target. The advisory's fix details should be checked for the patched version, which the title describes as rejecting trust keys without IDs.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
The checked facts give no workaround. Until a fix is available, the affected feature can be limited by avoiding supplying PKCS#8 keys to key_or_keyring restrictions through KEYCTL_RESTRICT_KEYRING.Source: git.kernel.org