CVE-2025-38488 in Linux
Summary
by MITRE • 07/28/2025
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in crypt_message when using async crypto
The CVE-2024-50047 fix removed asynchronous crypto handling from crypt_message(), assuming all crypto operations are synchronous. However, when hardware crypto accelerators are used, this can cause use-after-free crashes:
crypt_message() // Allocate the creq buffer containing the req creq = smb2_get_aead_req(..., &req);
// Async encryption returns -EINPROGRESS immediately rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);
// Free creq while async operation is still in progress kvfree_sensitive(creq, ...);
Hardware crypto modules often implement async AEAD operations for performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS, the operation completes asynchronously. Without crypto_wait_req(), the function immediately frees the request buffer, leading to crashes when the driver later accesses the freed memory.
This results in a use-after-free condition when the hardware crypto driver later accesses the freed request structure, leading to kernel crashes with NULL pointer dereferences.
The issue occurs because crypto_alloc_aead() with mask=0 doesn't guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in the mask, async implementations can be selected.
Fix by restoring the async crypto handling: - DECLARE_CRYPTO_WAIT(wait) for completion tracking - aead_request_set_callback() for async completion notification - crypto_wait_req() to wait for operation completion
This ensures the request buffer isn't freed until the crypto operation completes, whether synchronous or asynchronous, while preserving the CVE-2024-50047 fix.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 01/25/2026
The vulnerability described in CVE-2025-38488 represents a critical use-after-free condition within the Linux kernel's SMB client implementation, specifically affecting the crypt_message function during asynchronous cryptographic operations. This issue emerged as a regression following the resolution of CVE-2024-50047, which had previously addressed asynchronous crypto handling by assuming all cryptographic operations would complete synchronously. The fundamental flaw occurs when hardware crypto accelerators are employed, where the cryptographic subsystem may return -EINPROGRESS to indicate asynchronous operation completion, creating a temporal gap between request allocation and actual processing that leads to memory corruption.
The technical implementation details reveal a classic race condition in kernel memory management where the creq buffer containing the cryptographic request structure is allocated through smb2_get_aead_req() and immediately freed via kvfree_sensitive() without proper synchronization. When hardware crypto modules are active, the crypto_aead_encrypt() or crypto_aead_decrypt() functions return -EINPROGRESS, signaling that the operation has been queued for asynchronous completion. However, the original fix failed to account for this asynchronous behavior, causing the kernel to free the request structure while the hardware driver still references it, resulting in kernel crashes due to NULL pointer dereferences and memory corruption. This scenario directly maps to CWE-416, representing use-after-free vulnerabilities in memory management.
The operational impact of this vulnerability extends beyond simple system crashes, as it affects the stability and reliability of SMB client connections when hardware acceleration is enabled. Attackers could potentially exploit this condition to cause denial of service attacks against systems running affected kernel versions, particularly in enterprise environments where SMB file sharing is prevalent and hardware crypto accelerators are commonly deployed. The vulnerability affects systems using hardware crypto modules that implement asynchronous AEAD operations, making it particularly relevant in high-performance computing environments where crypto acceleration is utilized for network security protocols. This issue demonstrates the complexity of kernel crypto subsystem interactions and the challenges of maintaining compatibility between synchronous and asynchronous operation models.
The remediation approach involves restoring proper asynchronous crypto handling while preserving the security improvements from CVE-2024-50047 through the implementation of standard kernel crypto completion mechanisms. The fix introduces DECLARE_CRYPTO_WAIT(wait) for proper completion tracking, aead_request_set_callback() for async completion notification, and crypto_wait_req() to ensure operation completion before buffer deallocation. This approach aligns with established kernel security practices and follows the ATT&CK framework's concept of privilege escalation through kernel exploitation by addressing the root cause rather than merely patching symptoms. The solution ensures that cryptographic request buffers remain valid throughout the complete operation lifecycle, whether the underlying crypto implementation operates synchronously or asynchronously, thereby maintaining system stability while preserving the intended security hardening from the previous fix.