ghsa-26jg-99jv-7wgw
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2022-50731"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-24T13:15:59Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: akcipher - default implementation for setting a private key\n\nChanges from v1:\n * removed the default implementation from set_pub_key: it is assumed that\n an implementation must always have this callback defined as there are\n no use case for an algorithm, which doesn\u0027t need a public key\n\nMany akcipher implementations (like ECDSA) support only signature\nverifications, so they don\u0027t have all callbacks defined.\n\nCommit 78a0324f4a53 (\"crypto: akcipher - default implementations for\nrequest callbacks\") introduced default callbacks for sign/verify\noperations, which just return an error code.\n\nHowever, these are not enough, because before calling sign the caller would\nlikely call set_priv_key first on the instantiated transform (as the\nin-kernel testmgr does). This function does not have a default stub, so the\nkernel crashes, when trying to set a private key on an akcipher, which\ndoesn\u0027t support signature generation.\n\nI\u0027ve noticed this, when trying to add a KAT vector for ECDSA signature to\nthe testmgr.\n\nWith this patch the testmgr returns an error in dmesg (as it should)\ninstead of crashing the kernel NULL ptr dereference.",
"id": "GHSA-26jg-99jv-7wgw",
"modified": "2025-12-24T15:30:33Z",
"published": "2025-12-24T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50731"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/779a9930f3e152c82699feb389a0e6d6644e747e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/85bc736a18b872f54912e8bb70682d11770aece0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95c4e20adc3ea00d1594a2a05d9b187ed12ffa8e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a1354bdd191d533211b7cb723aa76a66f516f197"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc155c6c188c2f0c5749993b1405673d25a80389"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9058178597059d6307efe96a7916600f8ede08c"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.