CVE-2026-98387 in Linux
Summary
by MITRE • 10/15/2026
In the Linux kernel, the following vulnerability has been resolved:
s390/crypto: Fix skcipher_walk return code handling in aes_s390
The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory.
Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within the Linux kernel's s390 cryptographic subsystem involves a critical flaw in how error codes are handled during symmetric key cipher operations, specifically affecting the AES implementations for Electronic Codebook (ECB) and Counter (CTR) modes on IBM System z architecture. The core technical issue resides in the functions ecb_aes_crypt() and ctr_aes_crypt(), which rely on the skcipher_walk_virt() helper to manage data buffers during encryption or decryption processes. This helper function is responsible for setting up a walk structure that describes how input and output memory should be accessed, particularly handling cases where data spans multiple pages or requires special alignment considerations. In the vulnerable code paths, the return value from skcipher_walk_virt(), which indicates success or failure of this initialization step, was not being validated before proceeding to the main processing loops. This oversight means that if the walk function encountered an error—such as invalid parameters, memory allocation failures, or other internal kernel constraints—the subsequent cryptographic operations would proceed regardless of the failed setup state.
When skcipher_walk_virt() fails, it leaves the associated walk structure in an undefined or inconsistent state. By ignoring this failure and continuing execution, the code attempts to process data using pointers and lengths that may not have been correctly initialized or validated. This leads directly to a scenario where the kernel accesses uninitialized memory regions or operates on invalid buffer boundaries. In the context of cryptographic operations, which are often performed in sensitive contexts such as secure key exchange or encrypted storage access, accessing uninitialized memory can result in unpredictable behavior. The immediate operational impact includes potential data corruption, where ciphertext is generated from garbage input or plaintext is decrypted incorrectly, leading to application-level failures and loss of integrity for protected data. Furthermore, the use of invalid pointers constitutes a severe security risk that could be exploited by local attackers with sufficient privileges to trigger these code paths via specific cryptographic API calls, potentially leading to kernel crashes (denial of service) or information disclosure if sensitive memory contents are inadvertently read during the malformed processing loop.
From a vulnerability classification perspective, this flaw aligns closely with CWE-252, which covers unchecked return values, as the developer failed to verify the success status of a critical function call that dictates subsequent control flow and data safety. Additionally, because the error leads to accessing uninitialized memory, it also relates to CWE-908, use of uninitialized resource. In terms of attack vectorization within the MITRE ATT&CK framework for Linux systems, this type of flaw can be leveraged in techniques associated with privilege escalation or defense evasion if an attacker can force a kernel panic through repeated failures, thereby disrupting system availability (T1499: Endpoint Denial of Service). The lack of proper error propagation also hinders effective logging and monitoring, as the failure condition is silently ignored rather than reported up the stack for diagnostic purposes.
The resolution implemented in this fix involves inserting explicit checks on the return code from skcipher_walk_virt() immediately after its invocation within both ecb_aes_crypt() and ctr_aes_crypt(). If the function returns a non-zero value indicating an error, the cryptographic routine now correctly aborts further processing of that data chunk. Instead of attempting to use the potentially corrupted walk structure, the functions propagate this return code back to their caller, ensuring that the higher-level crypto API layer is aware of the failure and can handle it appropriately, such as by returning an error status to the user-space application or triggering a controlled kernel error path. This change ensures robustness against malformed inputs or resource exhaustion scenarios. To mitigate similar risks in other parts of the kernel, developers should adopt a strict policy of validating all return codes from memory management and buffer walking helpers before proceeding with data operations. Regular static analysis tools configured to detect unchecked returns can help identify such patterns early in the development lifecycle, preventing these types of logic errors from reaching production kernels where they could compromise system stability and security.