CVE-2025-38488

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free in crypt_message when using async crypto<br /> <br /> The CVE-2024-50047 fix removed asynchronous crypto handling from<br /> crypt_message(), assuming all crypto operations are synchronous.<br /> However, when hardware crypto accelerators are used, this can cause<br /> use-after-free crashes:<br /> <br /> crypt_message()<br /> // Allocate the creq buffer containing the req<br /> creq = smb2_get_aead_req(..., &amp;req);<br /> <br /> // Async encryption returns -EINPROGRESS immediately<br /> rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);<br /> <br /> // Free creq while async operation is still in progress<br /> kvfree_sensitive(creq, ...);<br /> <br /> Hardware crypto modules often implement async AEAD operations for<br /> performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,<br /> the operation completes asynchronously. Without crypto_wait_req(),<br /> the function immediately frees the request buffer, leading to crashes<br /> when the driver later accesses the freed memory.<br /> <br /> This results in a use-after-free condition when the hardware crypto<br /> driver later accesses the freed request structure, leading to kernel<br /> crashes with NULL pointer dereferences.<br /> <br /> The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;#39;t<br /> guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in<br /> the mask, async implementations can be selected.<br /> <br /> Fix by restoring the async crypto handling:<br /> - DECLARE_CRYPTO_WAIT(wait) for completion tracking<br /> - aead_request_set_callback() for async completion notification<br /> - crypto_wait_req() to wait for operation completion<br /> <br /> This ensures the request buffer isn&amp;#39;t freed until the crypto operation<br /> completes, whether synchronous or asynchronous, while preserving the<br /> CVE-2024-50047 fix.