CVE-2026-99220 in Linux
Summary
by MITRE • 11/02/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel contains a critical vulnerability within its asymmetric keys subsystem, specifically affecting the handling of PKCS#8 formatted cryptographic keys during keyring restriction operations. This flaw arises from an improper validation check in the code responsible for processing trust anchors and certificate chains. The Public Key Cryptography Standards #8 (PKCS#8) format is commonly used to store private keys, but it does not inherently contain information about public certificates or identity identifiers that are necessary for establishing a chain of trust. When a PKCS#8 key is supplied as part of a restriction applied to a keyring via the KEYCTL_RESTRICT_KEYRING system call followed by add_key(), the kernel attempts to validate this key against existing keys in the ring. The function key_or_keyring_common, located within crypto/asymmetric_keys/restrict.c, unconditionally dereferences a payload slot intended for asymmetric key identifiers (asym_key_ids). However, because PKCS#8 parsers deliberately leave this specific field empty as it is not applicable to private key formats, the pointer remains null. This leads directly to a NULL pointer dereference when the kernel attempts to access memory at address zero or near-zero offsets during the restriction validation process.
This vulnerability allows an unprivileged local user to trigger a denial of service condition by causing a general protection fault that results in a kernel panic and system crash. The attack vector involves crafting specific syscalls that invoke key creation with PKCS#8 keys under restrictive conditions targeting trust anchors or certificate chains. Since the flaw is triggered through standard Linux Key Management API calls, it does not require elevated privileges to initiate, although successful exploitation typically requires access to the user's session keyring. The operational impact is severe for systems relying on kernel-level cryptographic operations and secure boot mechanisms, as a single malicious syscall can destabilize the entire operating system. This aligns with CWE-476, which describes NULL Pointer Dereference vulnerabilities where software fails to check if an object reference is null before using it, leading to crashes or potential code execution in more complex scenarios involving memory corruption.
From a threat intelligence perspective, this vulnerability maps to MITRE ATT&CK technique T1529, specifically the System Shutdown/Reboot sub-technique, as the resulting kernel panic effectively halts system availability. It also relates to CWE-20 regarding improper input validation, where the application fails to verify that required data structures are properly initialized before use. The root cause is a logical error in the security module's assumption that all asymmetric keys provided for trust verification will possess valid identifier payloads. This oversight ignores the structural differences between public key certificates and private key containers like PKCS#8. To mitigate this risk, kernel developers have implemented a fix that explicitly rejects asymmetric restriction keys lacking valid identifiers. System administrators should ensure their Linux kernels are updated to versions containing this patch. Additionally, defensive coding practices in future developments must enforce strict validation of payload structures before dereferencing pointers derived from external or user-supplied cryptographic inputs, ensuring that format-specific constraints such as the absence of IDs in PKCS#8 keys are accounted for during trust anchor evaluation.