CVE-2026-93158 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
crypto: sa2ul - stop probe if context pool creation fails
sa_ul_probe() calls sa_init_mem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool.
Stop probing when sa_init_mem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel cryptographic subsystem for Texas Instruments' SA2UL hardware contains a critical initialization flaw within its probe routine. The vulnerability stems from improper error handling during device driver loading, specifically in the sa_ul_probe function which is responsible for initializing the security accelerator unit. During this process, the driver attempts to allocate a DMA pool via the sa_init_mem function to serve as storage for security context buffers required by cryptographic operations. However, the code fails to check the return value of this allocation call, effectively ignoring potential failure states such as memory exhaustion or hardware resource constraints. This oversight creates a scenario where the probe routine proceeds with subsequent initialization steps despite the absence of essential resources.
When pool creation fails, the driver continues its execution flow by attempting DMA setup and registering cryptographic algorithms with the kernel crypto API. It also populates child devices associated with the accelerator. These operations assume that the underlying memory infrastructure is fully operational and accessible. Since the context pool was never successfully created, any subsequent attempt to utilize these resources will result in undefined behavior or immediate system instability. The lack of validation means the driver presents itself as ready for use while lacking the fundamental components necessary to perform its designated security functions safely.
The operational impact of this vulnerability is severe and can lead to kernel panics or data corruption during runtime operations. When a cryptographic request is submitted by an application, it relies on the availability of context buffers within the DMA pool. Because these buffers do not exist due to the earlier ignored failure, memory access violations occur when the driver attempts to map or use non-existent structures. This can cause immediate system crashes, rendering the device unusable and potentially affecting other processes running on the same kernel instance. In security-critical environments, such instability undermines the reliability of encryption services provided by the hardware accelerator.
From a technical classification perspective, this issue aligns with CWE-252 unchecked return value, where software fails to verify that an operation completed successfully before proceeding. It also relates to CWE-703 improper check or handling of exceptional conditions during initialization sequences. In terms of attack surface and mitigation strategies, the primary defense is applying kernel patches that enforce strict error checking at every stage of device driver probing. Developers must ensure that resource allocation failures are immediately caught and handled by routing execution to appropriate cleanup paths without attempting further operations dependent on those resources.
To mitigate this vulnerability, system administrators should apply the latest security updates for their Linux distribution which include fixes for the sa2ul crypto driver. These patches modify the probe logic to halt initialization if context pool creation fails and correctly route the error state through power management cleanup routines. This prevents the driver from registering itself with a broken configuration that could lead to crashes during normal operation. Additionally, monitoring system logs for allocation failures during device startup can help identify environments where resource constraints might trigger this condition before it causes runtime instability.