GHSA-97R7-5J8W-Q49J
Vulnerability from github – Published: 2026-09-11 21:31 – Updated: 2026-09-14 15:32
VLAI
Details
In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: reject oversized encrypted_key_size in parse_tag_3_packet
parse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When encrypted_key_size > 64, decrypt_passphrase_encrypted_session_key() sets decrypted_key_size = encrypted_key_size and performs two out-of-bounds writes:
- crypto_skcipher_decrypt() writes encrypted_key_size bytes into decrypted_key[64] via scatterlist, overflowing into the parent ecryptfs_auth_tok struct.
- memcpy(crypt_stat->key, decrypted_key, decrypted_key_size) writes into crypt_stat->key[64], corrupting root_iv, keysig_list, and mutexes in ecryptfs_crypt_stat.
Only AES-192 (cipher code 0x08) enables this because it sets crypt_stat->key_size = 24 independently of encrypted_key_size, allowing crypto_skcipher_setkey() to succeed while encrypted_key_size exceeds ECRYPTFS_MAX_KEY_BYTES.
The PKI decryption path (parse_tag_65_packet) already validates decrypted_key_size <= ECRYPTFS_MAX_KEY_BYTES; the passphrase path omits this check.
Bound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also protects the 512-byte encrypted_key[] buffer, so the former 512-byte check is removed as redundant.
[tyhicks: Adjust the code comment to refer to macros representing the buffer sizes rather than mentioning the buffer size values since they may change in the future]
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2026-89607"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-11T20:19:45Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\necryptfs: reject oversized encrypted_key_size in parse_tag_3_packet\n\nparse_tag_3_packet() set encrypted_key_size from the Tag 3 packet body\nwithout bounding it against ECRYPTFS_MAX_KEY_BYTES (64). When\nencrypted_key_size \u003e 64, decrypt_passphrase_encrypted_session_key()\nsets decrypted_key_size = encrypted_key_size and performs two\nout-of-bounds writes:\n\n1. crypto_skcipher_decrypt() writes encrypted_key_size bytes into\n decrypted_key[64] via scatterlist, overflowing into the parent\n ecryptfs_auth_tok struct.\n2. memcpy(crypt_stat-\u003ekey, decrypted_key, decrypted_key_size) writes\n into crypt_stat-\u003ekey[64], corrupting root_iv, keysig_list, and\n mutexes in ecryptfs_crypt_stat.\n\nOnly AES-192 (cipher code 0x08) enables this because it sets\ncrypt_stat-\u003ekey_size = 24 independently of encrypted_key_size,\nallowing crypto_skcipher_setkey() to succeed while encrypted_key_size\nexceeds ECRYPTFS_MAX_KEY_BYTES.\n\nThe PKI decryption path (parse_tag_65_packet) already validates\ndecrypted_key_size \u003c= ECRYPTFS_MAX_KEY_BYTES; the passphrase path\nomits this check.\n\nBound encrypted_key_size against ECRYPTFS_MAX_KEY_BYTES (64) rather\nthan ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES (512). The 64-byte limit also\nprotects the 512-byte encrypted_key[] buffer, so the former 512-byte\ncheck is removed as redundant.\n\n[tyhicks: Adjust the code comment to refer to macros representing the\n buffer sizes rather than mentioning the buffer size values since they\n may change in the future]",
"id": "GHSA-97r7-5j8w-q49j",
"modified": "2026-09-14T15:32:31Z",
"published": "2026-09-11T21:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-89607"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14cb36a500a5a3afbc955dbf69dabc565f1a3b26"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2cd21340163494d312836c77c9fbfe2530b3d075"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33e050cac841498b5175f0f385eee903fd98863c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5babe9c177c364521e3e682b949c5a8c47f4a441"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a419c9ebfc9a40ee56aaad6dc68bfd67d400817b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ccd13eff0e7356d2aa28b127b577e4e5ad4563f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2802414081184f79a619ede178aeef3aa989793"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2152d491ae62d96a32ed59778680a242af1fbc6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Loading…
Loading…