Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.8
CVE-2025-38488: Linux Kernel Vulnerability: Linux SMB Client Use-After-Free Crash
CVE-2025-38488
Summary
A bug in the Linux kernel's SMB client can cause a crash when using hardware-based encryption. This happens when the kernel frees memory too quickly, before the encryption operation is complete. To fix this, the developers have updated the kernel to handle asynchronous encryption properly.
What to do
No fix is available yet. Check with your software vendor for updates.
Affected software
| Vendor | Product | Affected versions |
|---|---|---|
| linux | linux_kernel |
>= 5.10.237, < 5.10.241 >= 5.15.181, < 5.15.190 >= 6.1.128, < 6.1.147 >= 6.6.57, < 6.6.100 >= 6.11.4, < 6.12.40 >= 6.13, < 6.15.8 6.16 cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* |
| debian | debian_linux |
11.0 cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:* |
Original title
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 han...
Original description
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.
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.
nvd CVSS3.1
7.8
Vulnerability type
CWE-416
Use After Free
- https://git.kernel.org/stable/c/15a0a5de49507062bc3be4014a403d8cea5533de Patch
- https://git.kernel.org/stable/c/2a76bc2b24ed889a689fb1c9015307bf16aafb5b Patch
- https://git.kernel.org/stable/c/5d047b12f86cc3b9fde1171c02d9bccf4dba0632 Patch
- https://git.kernel.org/stable/c/6550b2bef095d0dd2d2c8390d2ea4c3837028833 Patch
- https://git.kernel.org/stable/c/8ac90f6824fc44d2e55a82503ddfc95defb19ae0 Patch
- https://git.kernel.org/stable/c/9a1d3e8d40f151c2d5a5f40c410e6e433f62f438 Patch
- https://git.kernel.org/stable/c/b220bed63330c0e1733dc06ea8e75d5b9962b6b6 Patch
- https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html Third Party Advisory
- https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html Third Party Advisory
Published: 28 Jul 2025 · Updated: 20 Jul 2026 · First seen: 7 Mar 2026