Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-38488

CVE-2025-38488: Linux Kernel Use-After-Free Vulnerability

CVE-2025-38488 is a use-after-free vulnerability in Linux Kernel's SMB client affecting async crypto operations. This flaw can cause kernel crashes when hardware crypto accelerators are used. This article covers technical details, affected versions, impact, and mitigation strategies.

Published:

CVE-2025-38488 Overview

CVE-2025-38488 is a use-after-free vulnerability [CWE-416] in the Linux kernel's SMB client, specifically in the crypt_message() function of the smb: client subsystem. The flaw stems from an incomplete fix for CVE-2024-50047, which removed asynchronous crypto handling under the assumption that all crypto operations complete synchronously. When hardware crypto accelerators return -EINPROGRESS, the request buffer is freed before the operation finishes, leading to kernel memory corruption. Exploitation requires local access with low privileges and can result in kernel crashes or memory corruption affecting confidentiality, integrity, and availability.

Critical Impact

A local, low-privileged user on a system using SMB mounts with hardware-accelerated AEAD crypto can trigger a kernel use-after-free, causing NULL pointer dereferences, crashes, and potential memory corruption in kernel space.

Affected Products

  • Linux Kernel (multiple stable branches, including 6.16-rc1 through 6.16-rc6)
  • Debian Linux 11.0
  • Systems using the SMB client with hardware crypto accelerators supporting async AEAD

Discovery Timeline

  • 2025-07-28 - CVE-2025-38488 published to NVD
  • 2026-07-30 - Last updated in NVD database

Technical Details for CVE-2025-38488

Vulnerability Analysis

The vulnerability resides in the crypt_message() function within the Linux kernel SMB client code. This function allocates a creq buffer containing an AEAD request, invokes crypto_aead_encrypt() or crypto_aead_decrypt(), and then frees the buffer via kvfree_sensitive(). The prior CVE-2024-50047 remediation removed the asynchronous completion handling because it was believed all crypto paths were synchronous.

Hardware crypto modules commonly implement AEAD operations asynchronously for throughput. When the underlying driver is async, crypto_aead_encrypt() returns -EINPROGRESS immediately and the operation completes on a separate context. Without crypto_wait_req() to block on completion, crypt_message() proceeds to free creq while the hardware driver still holds a live reference to it.

The attacker impact is a use-after-free when the crypto driver later dereferences the freed request structure. This produces NULL pointer dereferences, kernel oops conditions, and potentially exploitable memory corruption in a privileged context.

Root Cause

The root cause is an incorrect assumption about crypto API semantics. Calling crypto_alloc_aead() with mask=0 does not guarantee a synchronous implementation. Even without CRYPTO_ALG_ASYNC set in the mask, the crypto framework may bind the transform to an asynchronous hardware backend, breaking the caller's synchronous execution assumption.

Attack Vector

Exploitation requires local access with low privileges on a system mounting SMB shares while the kernel crypto subsystem selects an async AEAD implementation, typically via a hardware accelerator. Triggering SMB traffic that invokes crypt_message() such as reads or writes on an encrypted SMB3 mount can race the free against the async completion, producing the use-after-free condition. No user interaction is required. See the Linux kernel commit for the patch that restores async handling.

No public proof-of-concept exploit is currently available. The vulnerability manifests through the sequence: buffer allocation, async crypto invocation returning -EINPROGRESS, premature free via kvfree_sensitive(), and later access by the hardware driver to the freed memory.

Detection Methods for CVE-2025-38488

Indicators of Compromise

  • Kernel oops or panic logs referencing crypt_message, smb2_get_aead_req, or crypto_aead_encrypt/crypto_aead_decrypt in the call stack.
  • NULL pointer dereferences occurring shortly after SMB read/write activity on encrypted mounts.
  • KASAN reports flagging use-after-free in the SMB client module on kernels with KASAN enabled.

Detection Strategies

  • Audit installed kernel versions against the fixed commits listed in the vendor advisories to identify unpatched hosts.
  • Enable Kernel Address Sanitizer (KASAN) on test systems that mount SMB shares with hardware crypto accelerators to surface the use-after-free deterministically.
  • Correlate dmesg crash signatures with SMB client activity and loaded hardware crypto drivers such as ccp, qat, or caam.

Monitoring Recommendations

  • Forward kernel logs to a centralized logging pipeline and alert on BUG:, KASAN:, or general protection fault events referencing SMB or crypto symbols.
  • Track uptime and unexpected reboots on Linux fleet endpoints that use cifs.ko with encrypted SMB3 sessions.
  • Inventory systems where hardware crypto offload is enabled alongside SMB client usage to prioritize patching.

How to Mitigate CVE-2025-38488

Immediate Actions Required

  • Apply the upstream Linux kernel patches referenced in the stable tree commits, or upgrade to a distribution kernel that includes the fix.
  • For Debian 11 systems, install the updated kernel from the Debian LTS announcement.
  • Reboot affected systems after patching to load the corrected kernel image.

Patch Information

The fix restores asynchronous crypto handling in crypt_message() by adding DECLARE_CRYPTO_WAIT(wait) for completion tracking, calling aead_request_set_callback() to register async completion, and invoking crypto_wait_req() to block until the operation finishes. This ensures the creq buffer is not freed until the hardware driver releases its reference. See the mainline fix at git.kernel.org commit 8ac90f6 and additional stable backports 15a0a5d, 2a76bc2, and b220bed.

Workarounds

  • Where patching is not immediately possible, disable SMB3 encryption on client mounts by omitting the seal mount option to avoid invoking crypt_message().
  • Disable or unload hardware crypto accelerator modules so the crypto API falls back to synchronous software AEAD implementations, which are not affected by the async path.
  • Restrict local shell and container access on systems that mount encrypted SMB shares to reduce the population of users who can trigger the code path.

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.