CVE-2026-43493

What it actually does

The flaw is in the Linux kernel pcrypt crypto template, which parallelizes cryptographic operations across CPUs. Requests marked MAY_BACKLOG may legitimately return EBUSY when the async crypto queue is full; the vulnerable code mishandles that condition and does not correctly filter EINPROGRESS notifications. This can create incorrect request-completion handling and kernel crypto state confusion. In affected kernels, a reachable crypto consumer that uses pcrypt-backed asynchronous operations could potentially trigger kernel instability, memory-safety side effects, or broader confidentiality, integrity, and availability impact depending on how the vulnerable path is exercised.

Why it matters to the business

Systems running affected Linux kernels may be exposed to a high-severity kernel-level flaw in a core cryptographic subsystem. If an exposed workload or network-facing feature routes attacker-controlled traffic into pcrypt-backed crypto operations, exploitation could disrupt services or, in a worst case, compromise the host at kernel privilege. This issue is not currently listed in CISA KEV, has low EPSS, and has no reported public exploit maturity in the provided data, but the high CVSS score means patching should still be prioritized for internet-facing, VPN/IPsec, encryption-heavy, and multi-tenant Linux systems.

How an attack unfolds

An attacker first identifies a Linux system or service path that causes the kernel to perform asynchronous pcrypt-backed cryptographic work, such as a network or local interface using the kernel crypto API. The attacker then sends crafted or high-volume requests that force the crypto queue into a backlog condition where MAY_BACKLOG requests return EBUSY. On vulnerable kernels, the pcrypt code mishandles this return path and related EINPROGRESS notifications, causing request lifecycle confusion. Depending on the exact kernel build, crypto consumer, timing, and memory layout, the result may be a kernel crash, incorrect crypto request handling, or potentially more severe kernel compromise. There are no provided indicators that this CVE is currently exploited in the wild.

How to fix it

Upgrade affected Linux kernels to a vendor-supported version that includes the upstream fix titled "crypto: pcrypt - Fix handling of MAY_BACKLOG requests." Because no exact fixed versions were provided, use the security advisory from the Linux distribution or appliance vendor and verify that the pcrypt MAY_BACKLOG/EBUSY handling patch is included. Prioritize kernel updates on internet-facing systems, VPN/IPsec gateways, systems using kernel crypto acceleration, container hosts, and multi-tenant platforms. If immediate patching is not possible, reduce exposure by disabling or avoiding pcrypt-backed crypto configurations where feasible, unloading the pcrypt module if it is not required and not built in, restricting untrusted local access to kernel crypto interfaces such as AF_ALG, rate-limiting untrusted traffic that exercises crypto-heavy paths, and applying standard kernel hardening controls. Reboot is normally required for kernel remediation to take effect.

How to confirm the fix worked

Confirm the running kernel is the patched vendor build, not just that an updated package is installed. Validate with commands such as `uname -r`, package-manager queries, and vendor changelog checks for the fix text "crypto: pcrypt - Fix handling of MAY_BACKLOG requests." Check whether pcrypt is present or loaded using `lsmod | grep pcrypt`, `/proc/crypto`, kernel config files such as `/boot/config-$(uname -r)`, or distribution-specific module metadata. Where possible, verify the source or binary package contains the corrected handling for MAY_BACKLOG returning EBUSY and filtering of EINPROGRESS notifications. After patching, reboot into the fixed kernel and confirm the old vulnerable kernel is not still active. For mitigation validation, confirm pcrypt is not loaded or used where it is not required and that untrusted access paths to kernel crypto functionality are restricted.

Typical attack path

1. Identify a target running an affected Linux kernel version.
2. Determine whether pcrypt or a pcrypt-backed crypto consumer is reachable through a network service, VPN/IPsec path, kernel crypto API user, container workload, or local interface.
3. Generate attacker-controlled crypto workloads that allow MAY_BACKLOG requests and pressure the async crypto queue.
4. Trigger an EBUSY return condition and the vulnerable pcrypt completion-notification handling path.
5. Leverage the resulting kernel fault or request-state confusion to cause denial of service or attempt further kernel-level exploitation.

How to detect it

There are no reliable CVE-specific exploitation indicators provided for this issue, and kernel crypto exploitation may leave little application-level evidence. Review kernel logs from `dmesg`, journald, syslog, netconsole, crash dumps, and vmcores for oops, BUG, panic, use-after-free, NULL-pointer dereference, hung task, or general protection fault messages involving `pcrypt`, `crypto`, async crypto requests, or IPsec/VPN processing. Correlate any such events with spikes in encrypted network traffic, VPN/IPsec negotiation or payload volume, AF_ALG usage, container workload activity, or untrusted local processes generating high crypto request rates. On systems with crash dump collection, analyze stack traces for pcrypt and crypto API frames. Also review authentication and process execution logs for untrusted users or workloads that may have accessed kernel crypto interfaces. Absence of these artifacts does not prove absence of exploitation because the vulnerability is in kernel request handling rather than a protocol with stable wire-level signatures.

What your security team should do

• Inventory Linux systems and identify kernel versions, with priority on externally exposed, VPN/IPsec, encryption-heavy, container-host, and multi-tenant systems.
• Map where pcrypt or kernel crypto API consumers are enabled, including loaded modules, `/proc/crypto`, IPsec/VPN configurations, and workloads using AF_ALG or kernel crypto offload.
• Apply vendor kernel updates that include the pcrypt MAY_BACKLOG/EBUSY fix and reboot into the fixed kernel.
• Where patching is delayed, disable unnecessary pcrypt usage, restrict untrusted local access to kernel crypto interfaces, and reduce exposure of crypto-heavy network paths.
• Monitor kernel logs for crashes, warnings, or oops traces involving pcrypt or the crypto subsystem, especially after bursts of VPN, IPsec, or other encrypted traffic.
• Treat unexplained kernel crashes on unpatched systems as potentially security-relevant and preserve logs, vmcores, and workload/network context for forensic review.
• Track vendor advisories because exact fixed package versions were not provided and may differ by distribution or downstream kernel branch.