CVE-2026-93155 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: keembay - Fix AEAD unregister count in error path
register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms. If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size.
Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered. Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel cryptographic subsystem contains a logic error in the Keembay hardware acceleration driver related to resource cleanup during initialization failures. The vulnerability arises from an incorrect array size specification when unwinding previously registered algorithms upon partial failure of the module load process. Specifically, the register_aes_algs function is responsible for registering both AEAD and skcipher algorithm types with the kernel crypto framework. To maintain consistency in case of errors, the driver must unregister any successfully registered components before aborting initialization. However, the error handling path incorrectly invokes the cleanup routine using ARRAY_SIZE(algs), which corresponds to the size of the skcipher table rather than the AEAD table that was actually registered first.
This mismatch results in a buffer over-read or out-of-bounds access because the unregister helper attempts to iterate through more entries than exist in the AEAD algorithm array. Since crypto_engine_unregister_aeads expects an exact count matching the number of previously registered items, passing a larger value derived from a different data structure causes the function to read memory beyond the bounds of the algs_aead array. This constitutes a classic out-of-bounds read vulnerability that can lead to kernel instability or information disclosure depending on what memory contents follow the allocated AEAD structures in physical memory.
From an industry standard perspective, this flaw aligns with CWE-125 Out-of-bounds Read and CWE-787 Out-of-bounds Write if the cleanup routine modifies state based on invalid counts. The issue also reflects poor defensive programming practices where error paths do not mirror the success path's resource management logic precisely. In terms of MITRE ATT&CK, this could potentially be leveraged for information gathering or denial of service by triggering a kernel panic through repeated module load failures in controlled environments, although exploitation typically requires local access and specific timing conditions to trigger the initialization failure sequence.
The operational impact includes potential system crashes during driver loading if skcipher registration fails after AEAD algorithms have been successfully registered. This affects systems relying on Intel Keembay SoCs for cryptographic operations via hardware acceleration. Administrators may experience unexpected reboots or degraded performance if the kernel enters an unstable state due to corrupted internal crypto framework structures resulting from the erroneous cleanup routine.
Mitigation strategies involve applying vendor-provided patches that correct the array size reference in the error handling code path. Developers should ensure that all resource unwinding operations explicitly use constants or variables corresponding exactly to the resources they are intended to release, avoiding reliance on generic table sizes unless those tables contain homogeneous entries of identical type and count. Code review processes must emphasize symmetry between registration and deregistration logic to prevent such discrepancies in complex initialization sequences involving multiple subsystems within the kernel crypto framework.