CVE-2022-50731 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
crypto: akcipher - default implementation for setting a private key
Changes from v1: * removed the default implementation from set_pub_key: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public key
Many akcipher implementations (like ECDSA) support only signature verifications, so they don't have all callbacks defined.
Commit 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") introduced default callbacks for sign/verify operations, which just return an error code.
However, these are not enough, because before calling sign the caller would likely call set_priv_key first on the instantiated transform (as the in-kernel testmgr does). This function does not have a default stub, so the kernel crashes, when trying to set a private key on an akcipher, which doesn't support signature generation.
I've noticed this, when trying to add a KAT vector for ECDSA signature to the testmgr.
With this patch the testmgr returns an error in dmesg (as it should) instead of crashing the kernel NULL ptr dereference.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 04/21/2026
The vulnerability CVE-2022-50731 resides within the Linux kernel's cryptographic subsystem, specifically in the asymmetric cipher (akcipher) framework where improper handling of private key setting operations leads to kernel crashes. This issue affects the default implementation mechanisms that govern how cryptographic algorithms handle key operations, particularly when dealing with algorithms that may not support all possible key operations. The vulnerability stems from a design flaw in the kernel's cryptographic API where certain callback functions lack proper default implementations, creating a path for null pointer dereferences during kernel operation. The problem manifests when cryptographic implementations attempt to set private keys on algorithms that are designed for specific operations such as signature verification, where private key setting is not a supported function. This vulnerability impacts the core cryptographic infrastructure of the Linux kernel, potentially allowing for denial of service conditions or system instability when cryptographic operations are performed.
The technical flaw occurs in the akcipher framework where the set_priv_key callback function lacks a default implementation, while other related callbacks such as sign/verify operations have been provided with default error-returning implementations. This inconsistency creates a scenario where algorithms like ECDSA that support only signature verification operations can cause kernel crashes when the kernel attempts to call set_priv_key on a transform that has not implemented this specific callback function. The vulnerability is particularly concerning because it affects the kernel's internal test management framework (testmgr) which is used for validating cryptographic implementations. When the testmgr attempts to set a private key on an algorithm that doesn't support this operation, the missing default implementation causes a null pointer dereference, leading to immediate system crash rather than graceful error handling.
The operational impact of this vulnerability extends beyond simple system crashes to potentially affect the reliability and security of cryptographic operations throughout the Linux kernel. When exploited, this vulnerability can cause denial of service conditions that impact system availability, particularly in environments where cryptographic operations are frequently performed. The vulnerability is especially dangerous because it affects the kernel's internal testing infrastructure, which means that even routine validation processes can cause system instability. The issue affects various cryptographic implementations that rely on the akcipher framework, particularly those implementing signature verification algorithms where private key operations are not supported. This vulnerability can be triggered through legitimate kernel operations, making it difficult to distinguish between normal usage and malicious exploitation attempts, and potentially allowing for persistent denial of service attacks against critical system services.
Mitigation strategies for CVE-2022-50731 involve ensuring that all cryptographic implementations properly define their callback functions or that appropriate default implementations are provided for all required operations. The fix implemented in the kernel addresses this by removing the default implementation from set_pub_key and enforcing that implementations must always define the set_pub_key callback, thereby preventing the null pointer dereference scenario. System administrators should ensure their kernels are updated to versions containing this fix, particularly in production environments where cryptographic operations are frequent. Additionally, monitoring systems should be configured to detect unusual patterns in kernel crash reports or cryptographic operation failures that might indicate exploitation attempts. The vulnerability demonstrates the importance of consistent callback implementation patterns in kernel cryptographic frameworks and highlights the need for comprehensive testing of cryptographic implementations, especially those that may not support all possible operations. Organizations should also consider implementing proper error handling mechanisms in their cryptographic applications to gracefully handle cases where cryptographic operations are not supported by underlying implementations. This vulnerability aligns with CWE-476 which deals with NULL pointer dereferences, and represents a specific case of improper handling of cryptographic API callbacks that can be mapped to ATT&CK technique T1499.004 for denial of service through resource exhaustion, as the crash can be triggered repeatedly to cause system instability.