The flaw originates in the ecryptfs parse_tag_3_packet function, which assigns an encrypted key size to the buffer without bounding it against ECRYPTFS_MAX_KEY_BYTES (64). During decryption, crypto_skcipher_decrypt writes‑byte array and memcpy copies the oversized payload into another 64‑byte array, corrupting critical kernel structures such as root_iv, keysig_list, and mutexes. This double out‑of‑bounds write can corrupt kernel heap memory, potentially enabling an attacker to execute arbitrary code or crash the system. Only the AES‑192 cipher path is vulnerable because it sets a fixed key size of 24 bytes while allowing an oversized encrypted_key_size, giving the attacker the necessary conditions to trigger the overflow. The vulnerability essentially permits kernel memory corruption through the ecryptfs encryption layer, exposing the system to code execution or denial of service. No abuse of the flaw is formally documented in external advisories beyond the bug fix, but the description demonstrates that the conditions for exploitation exist.

All Linux kernel releases that contain the ecryptfs implementation and have not incorporated the commit that bounds encrypted_key_size in specific to kernel configurations that enable AES‑192 for ecryptfs; any kernel using that cipher in ecryptfs is susceptible so any kernel prior to the patch that contains the vulnerable function should be assumed at risk.

The CVSS score of 7.8 denotes high severity, while the EPSS score of less than 1 % indicates a low current exploitation probability. Because it is not listed in the CISA KEV catalog, the vulnerability has not been observed in widespread targeted attacks. The likely attack vector involves creating or manipulating an ecryptfs encrypted file with a crafted Tag 3 packet, which, when decrypted, triggers the out‑of‑bounds writes. An attacker with write access to an ecryptfs mount can exploit the flaw to corrupt kernel memory, potentially achieving code execution or causing a system crash. No public exploit is reported in the CVE data, but the existence of an exploitable kernel OOB write is well documented.