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.
Metrics
Affected Vendors & Products
No data.
No data.
OpenCVE Enrichment is a feature of OpenCVE that uses AI to automatically link vendors and products to CVEs. Learn more on GitHub.
| Vendors | Products |
|---|---|
|
Linux
Subscribe
|
Linux Kernel
Subscribe
|
Advisories
| Source | ID | Title |
|---|---|---|
 Debian DLA |
DLA-4327-1 | linux security update |
| Debian DLA |
DLA-4328-1 | linux-6.1 security update |
 Debian DSA |
DSA-5973-1 | linux security update |
| Debian DSA |
DSA-5975-1 | linux security update |
 EUVD |
EUVD-2025-22875 | 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. |
 Ubuntu USN |
USN-7879-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7879-2 | Linux kernel (Real-time) vulnerabilities |
| Ubuntu USN |
USN-7880-1 | Linux kernel (OEM) vulnerabilities |
| Ubuntu USN |
USN-7879-3 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7909-1 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7879-4 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7909-2 | Linux kernel (Real-time) vulnerabilities |
| Ubuntu USN |
USN-7909-3 | Linux kernel (FIPS) vulnerabilities |
| Ubuntu USN |
USN-7910-1 | Linux kernel (Azure FIPS) vulnerabilities |
| Ubuntu USN |
USN-7909-4 | Linux kernel vulnerabilities |
| Ubuntu USN |
USN-7910-2 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7909-5 | Linux kernel (Raspberry Pi) vulnerabilities |
| Ubuntu USN |
USN-7933-1 | Linux kernel (KVM) vulnerabilities |
| Ubuntu USN |
USN-7934-1 | Linux kernel (Azure) vulnerabilities |
| Ubuntu USN |
USN-7938-1 | Linux kernel (Azure) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Mon, 03 Nov 2025 18:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Thu, 28 Aug 2025 14:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Tue, 29 Jul 2025 12:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Tue, 29 Jul 2025 08:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Linux
Linux linux Kernel |
|
| Vendors & Products |
Linux
Linux linux Kernel |
Mon, 28 Jul 2025 11:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | smb: client: fix use-after-free in crypt_message when using async crypto | |
| References |
|
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2025-11-03T17:38:58.858Z
Reserved: 2025-04-16T04:51:24.021Z
Link: CVE-2025-38488
Vulnrichment
No data.
NVD
Status : Awaiting Analysis
Published: 2025-07-28T12:15:30.857
Modified: 2025-11-03T18:16:25.283
Link: CVE-2025-38488
Redhat
OpenCVE Enrichment
Updated: 2025-07-29T07:59:24Z
Weaknesses
No weakness.