fkie_cve-2025-38488
Vulnerability from fkie_nvd
Published
2025-07-28 12:15
Modified
2025-07-29 14:14
Severity ?
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: smb: cliente: correcci\u00f3n del use-after-free en crypt_message al usar criptograf\u00eda as\u00edncrona. La correcci\u00f3n CVE-2024-50047 elimin\u00f3 el manejo de criptograf\u00eda as\u00edncrona de crypt_message(), asumiendo que todas las operaciones de criptograf\u00eda son s\u00edncronas. Sin embargo, cuando se usan aceleradores de criptograf\u00eda de hardware, esto puede causar fallos de use-after-free: crypt_message() // Asignar el b\u00fafer creq que contiene la solicitud creq = smb2_get_aead_req(..., \u0026amp;req); // El cifrado as\u00edncrono devuelve -EINPROGRESS inmediatamente rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req); // Liberar creq mientras la operaci\u00f3n as\u00edncrona a\u00fan est\u00e1 en progreso kvfree_sensitive(creq, ...); Los m\u00f3dulos de criptograf\u00eda de hardware a menudo implementan operaciones AEAD as\u00edncronas para mejorar el rendimiento. Cuando crypto_aead_encrypt/decrypt() devuelve -EINPROGRESS, la operaci\u00f3n se completa de forma as\u00edncrona. Sin crypto_wait_req(), la funci\u00f3n libera inmediatamente el b\u00fafer de solicitud, lo que provoca fallos cuando el controlador accede posteriormente a la memoria liberada. Esto genera una condici\u00f3n de use-after-free cuando el controlador de cifrado de hardware accede posteriormente a la estructura de solicitud liberada, lo que provoca fallos del kernel con desreferencias de punteros NULL. El problema se produce porque crypto_alloc_aead() con mask=0 no garantiza la operaci\u00f3n s\u00edncrona. Incluso sin CRYPTO_ALG_ASYNC en la m\u00e1scara, se pueden seleccionar implementaciones as\u00edncronas. Soluci\u00f3n restaurando el manejo de criptograf\u00eda as\u00edncrona: - DECLARE_CRYPTO_WAIT(wait) para seguimiento de finalizaci\u00f3n - aead_request_set_callback() para notificaci\u00f3n de finalizaci\u00f3n as\u00edncrona - crypto_wait_req() para esperar a que se complete la operaci\u00f3n Esto garantiza que el b\u00fafer de solicitud no se libere hasta que se complete la operaci\u00f3n de criptograf\u00eda, ya sea sincr\u00f3nica o asincr\u00f3nica, al tiempo que se conserva la correcci\u00f3n CVE-2024-50047."
}
],
"id": "CVE-2025-38488",
"lastModified": "2025-07-29T14:14:29.590",
"metrics": {},
"published": "2025-07-28T12:15:30.857",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/15a0a5de49507062bc3be4014a403d8cea5533de"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2a76bc2b24ed889a689fb1c9015307bf16aafb5b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/8ac90f6824fc44d2e55a82503ddfc95defb19ae0"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9a1d3e8d40f151c2d5a5f40c410e6e433f62f438"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b220bed63330c0e1733dc06ea8e75d5b9962b6b6"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
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.
Loading…
Loading…