ghsa-8gh3-6693-hwj4
Vulnerability from github
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.
{
"affected": [],
"aliases": [
"CVE-2025-38488"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-28T12:15:30Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in crypt_message when using async crypto\n\nThe CVE-2024-50047 fix removed asynchronous crypto handling from\ncrypt_message(), assuming all crypto operations are synchronous.\nHowever, when hardware crypto accelerators are used, this can cause\nuse-after-free crashes:\n\n crypt_message()\n // Allocate the creq buffer containing the req\n creq = smb2_get_aead_req(..., \u0026req);\n\n // Async encryption returns -EINPROGRESS immediately\n rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);\n\n // Free creq while async operation is still in progress\n kvfree_sensitive(creq, ...);\n\nHardware crypto modules often implement async AEAD operations for\nperformance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,\nthe operation completes asynchronously. Without crypto_wait_req(),\nthe function immediately frees the request buffer, leading to crashes\nwhen the driver later accesses the freed memory.\n\nThis results in a use-after-free condition when the hardware crypto\ndriver later accesses the freed request structure, leading to kernel\ncrashes with NULL pointer dereferences.\n\nThe issue occurs because crypto_alloc_aead() with mask=0 doesn\u0027t\nguarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in\nthe mask, async implementations can be selected.\n\nFix by restoring the async crypto handling:\n- DECLARE_CRYPTO_WAIT(wait) for completion tracking\n- aead_request_set_callback() for async completion notification\n- crypto_wait_req() to wait for operation completion\n\nThis ensures the request buffer isn\u0027t freed until the crypto operation\ncompletes, whether synchronous or asynchronous, while preserving the\nCVE-2024-50047 fix.",
"id": "GHSA-8gh3-6693-hwj4",
"modified": "2025-07-28T12:30:35Z",
"published": "2025-07-28T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38488"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/15a0a5de49507062bc3be4014a403d8cea5533de"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a76bc2b24ed889a689fb1c9015307bf16aafb5b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8ac90f6824fc44d2e55a82503ddfc95defb19ae0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9a1d3e8d40f151c2d5a5f40c410e6e433f62f438"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b220bed63330c0e1733dc06ea8e75d5b9962b6b6"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.