CVE-2026-53046

What it actually does

This is a Linux kernel use-after-free in the ksmbd SMB server path when SMB cryptographic operations are handled by asynchronous hardware crypto engines, specifically noted with the Qualcomm Crypto Engine. ksmbd incorrectly treats an asynchronous -EINPROGRESS result as an immediate failure, frees the AEAD request/work structure while DMA is still in progress, and the later crypto completion path dereferences freed memory. The documented outcome is a kernel NULL pointer dereference and crash; because this occurs in kernel memory management around asynchronous DMA completion, it should be treated primarily as a remote or network-adjacent denial-of-service risk for systems running ksmbd on affected hardware, with memory-corruption implications that warrant prompt patching.

Why it matters to the business

An attacker who can reach an exposed ksmbd SMB service may be able to crash affected Linux systems, interrupting file sharing, embedded appliance functions, NAS workloads, edge devices, or other services that depend on SMB availability. Risk is highest for systems using ksmbd together with asynchronous hardware crypto acceleration such as Qualcomm Crypto Engine. The CVE is not currently listed in CISA KEV, is not marked as ransomware-used, and has low EPSS at this time, but kernel-level network service crashes can still create meaningful operational outages where SMB is business-critical.

How an attack unfolds

An attacker first identifies a Linux host exposing the in-kernel ksmbd SMB service. If the host uses an affected kernel build and an asynchronous crypto engine such as QCE, the attacker initiates SMB traffic that causes ksmbd to perform message cryptographic processing, such as SMB3 encrypted or otherwise crypto-protected operations. The crypto request is submitted to the hardware engine, which returns -EINPROGRESS to indicate asynchronous completion. Vulnerable ksmbd code misinterprets this as a hard failure and frees the request or associated work structure. When the DMA-backed crypto operation later completes, the completion path attempts to access memory that has already been freed, causing a kernel crash with stack traces involving qce_skcipher_done, vchan_complete, and ksmbd cleanup routines. Public exploit maturity is currently listed as none, so defenders should prioritize exposure reduction and patching rather than assuming commodity exploitation is widespread.

How to fix it

Upgrade to a Linux kernel version that includes the ksmbd fix using the standard crypto_wait_req() and crypto_req_done() completion handling pattern for AEAD requests. No exact fixed package versions were provided in the input, so obtain the corrected kernel from the relevant distribution, appliance vendor, Android/embedded BSP provider, or upstream stable kernel branch. If immediate patching is not possible, disable ksmbd where it is not required, replace it with a patched supported SMB implementation where appropriate, restrict SMB exposure to trusted networks, block inbound SMB from untrusted segments, and consider disabling affected hardware crypto acceleration only if vendor-supported and operationally safe. Reboot after kernel updates to ensure the fixed kernel is running.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated to a build containing the ksmbd async crypto fix. Verify whether ksmbd is loaded or active using standard host checks such as lsmod, modinfo, systemd service status, and SMB listener validation. On affected hardware, confirm the crypto engine driver is present only where expected and test SMB access after patching to ensure normal operation. Review distribution or vendor advisories for the exact backported patch identifier because fixed version numbers can differ across kernel branches. Validate network exposure by confirming TCP/445 is not reachable from untrusted networks unless explicitly required.

Typical attack path

1. Scan for hosts exposing SMB services over TCP/445 or otherwise reachable SMB ports.
2. Determine or infer that the SMB service is Linux ksmbd rather than Samba user-space smbd, where possible.
3. Target hosts likely to use affected kernel versions and asynchronous hardware crypto acceleration, especially Qualcomm-based systems.
4. Establish an SMB session that exercises ksmbd cryptographic message handling, such as SMB3 encryption-related paths.
5. Send crafted or repeated SMB operations that cause AEAD requests to be submitted to the asynchronous crypto engine.
6. Trigger the erroneous -EINPROGRESS handling path so ksmbd frees crypto request state prematurely.
7. Wait for the hardware crypto completion callback to dereference freed memory, resulting in a kernel NULL pointer dereference or panic.
8. Use the crash to deny service, force reboot loops, disrupt file access, or mask other activity.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, persistent journal records, crash dumps, netconsole output, pstore/ramoops, appliance support bundles, and monitoring alerts for unexpected reboots or kernel panics. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, /var/crash, /sys/fs/pstore, kdump/vmcore records, and SMB service logs around the time of the crash. Correlate crash times with inbound SMB connections, authentication attempts, session setup, tree connect, encrypted SMB3 traffic, or unusual bursts of SMB requests from a single source. Crash stacks containing qce_skcipher_done, vchan_complete, ksmbd_free_work_struct, ksmbd_exit_file_cache, ksmbd_crypt_message, or el1h_64_irq on systems using ksmbd and Qualcomm Crypto Engine are strong indicators that this bug was triggered. Because the primary observable is a kernel crash rather than a durable file artifact, absence of logs after reboot does not rule out exploitation if crash persistence was not configured.

• qce_skcipher_done
• vchan_complete
• ksmbd_free_work_struct
• ksmbd_exit_file_cache
• ksmbd_crypt_message
• el1h_64_irq
• Unable to handle kernel NULL pointer dereference
• Internal error: Oops
• Kernel panic - not syncing
• ksmbd
• qce
• Qualcomm Crypto Engine
• -EINPROGRESS

What your security team should do

• Prioritize inventory of Linux systems running ksmbd, especially NAS, embedded, edge, router, appliance, and Qualcomm-based platforms.
• Patch affected kernels through the OS, appliance, or BSP vendor and reboot to activate the fixed kernel.
• Temporarily disable ksmbd on systems where SMB service is not required.
• Restrict SMB access to trusted management or user networks; block TCP/445 from the internet and untrusted segments.
• Monitor kernel logs for crash signatures involving ksmbd, qce_skcipher_done, vchan_complete, crypto completion, NULL pointer dereference, or use-after-free symptoms.
• Treat unexplained kernel panics on SMB-serving Qualcomm-based systems as potentially security-relevant and preserve logs before reboot rotation removes evidence.
• Track vendor advisories because fixed versions were not supplied and backport status will vary by Linux distribution and appliance vendor.
• Do not rely solely on EPSS or KEV status for prioritization where SMB availability is critical or the device is remotely reachable.