CVE-2026-64312

What it actually does

This flaw is a Linux kernel crypto subsystem availability issue in the pcrypt AEAD fallback path. When pcrypt attempts to process an AEAD request through padata and padata_do_parallel() returns -EBUSY, the code falls back to submitting the request directly to the child AEAD implementation. Before the fix, the fallback path could leave pcrypt_aead_done() installed as the completion callback even though the request was not actually enrolled in padata. If the child AEAD operation completed asynchronously, the kernel could invoke a callback that assumes padata state exists, potentially causing invalid state handling, kernel warnings, request corruption, oops, or panic. The expected impact is denial of service; the CVSS vector indicates no confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can cause affected Linux systems to become unstable or crash, interrupting services that depend on the host. The risk is most important for internet-facing or high-throughput systems that use kernel crypto paths, such as VPN/IPsec gateways, encrypted network services, storage encryption, or appliances built on Linux. Although the EPSS score is currently low and the issue is not listed in CISA KEV, the CVSS availability impact is high, so organizations should treat it as a reliability and uptime risk, especially for critical infrastructure and service-provider workloads.

How an attack unfolds

An attacker would need to drive traffic or operations that cause the target system to perform AEAD cryptographic processing through the Linux kernel pcrypt layer. Under the vulnerable condition, pcrypt first installs its padata completion callback on the child AEAD request and attempts to submit the request for parallel processing. If the padata queue is busy and padata_do_parallel() returns -EBUSY, the code falls back to direct child AEAD execution. On vulnerable kernels, that fallback may retain the padata-oriented callback. If the underlying AEAD operation completes asynchronously, the kernel invokes pcrypt_aead_done() for a request that was never registered with padata, producing inconsistent completion handling and potentially crashing the kernel. Practical exploitation would likely involve repeatedly generating crypto workload, possibly during periods of CPU or padata pressure, until the race/fallback condition is triggered.

How to fix it

Upgrade the Linux kernel to a version that includes the pcrypt fix restoring the original request callback and callback data before direct fallback execution. If vendor fixed versions are not yet available in asset metadata, obtain the patched kernel from the relevant Linux distribution or appliance vendor and prioritize systems using kernel crypto features. Where immediate patching is not possible, reduce exposure by limiting untrusted access to services that drive kernel AEAD operations, rate-limit encrypted traffic paths where feasible, avoid unnecessary use of the pcrypt module, and ensure high-availability failover is in place for critical systems. Because this is a kernel flaw, application-level restarts are insufficient; remediation requires a patched kernel and reboot into that kernel unless a vendor-supported live patch is available.

How to confirm the fix worked

Confirm remediation by verifying that each system is running a vendor kernel build that contains the upstream pcrypt callback restoration fix for this issue. Check the running kernel version with standard package and runtime inventory tools, and ensure the system has rebooted into the fixed kernel rather than merely installing it. Validate exposure by checking whether the pcrypt module is loaded or available, whether kernel crypto users rely on AEAD algorithms, and whether services such as IPsec/VPN, encrypted tunneling, or storage encryption are active. For regression validation, run controlled cryptographic workload tests in a non-production environment and confirm no kernel oops, panic, or pcrypt/padata warnings appear under load.

Typical attack path

1. Identify a reachable service or protocol path on the target that causes the Linux kernel to perform AEAD cryptographic operations using pcrypt, such as encrypted network traffic or kernel-managed cryptographic workloads.
2. Generate repeated or high-volume requests that force AEAD operations and increase contention in the padata/pcrypt processing path.
3. Cause padata_do_parallel() to return -EBUSY, forcing pcrypt into its non-parallel fallback path.
4. Trigger asynchronous completion of the child AEAD request while the incorrect pcrypt/padata callback is still installed.
5. Cause invalid callback handling in the kernel, potentially resulting in kernel oops, panic, service interruption, or host reboot.

How to detect it

Look for evidence of prior exploitation or triggering by reviewing kernel logs, crash dumps, and uptime/reboot records around periods of heavy encrypted traffic. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, dmesg output, kdump/vmcore artifacts, hypervisor reset events, appliance crash reports, and monitoring alerts for unexpected host reboots. Focus on kernel oops or panic traces that mention pcrypt_aead_done, pcrypt, padata, crypto AEAD, asynchronous crypto completion, or request callback handling. Correlate any crash with spikes in encrypted network traffic, IPsec/VPN sessions, tunnel renegotiations, or other kernel crypto workload. Because no public exploit maturity is reported and the issue is not in KEV, absence of clear exploit-specific strings does not prove safety; detection is primarily crash-forensics and workload correlation rather than signature-based network detection.

• pcrypt_aead_done
• padata_do_parallel
• pcrypt
• padata
• crypto: pcrypt
• AEAD
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• unable to handle kernel NULL pointer dereference

What your security team should do

• Prioritize patching Linux systems that are internet-facing, handle encrypted traffic at scale, or provide critical availability functions.
• Inventory systems using the Linux pcrypt module, padata, IPsec/VPN, or other kernel AEAD crypto paths to identify likely exposure.
• Monitor vendor advisories for exact distribution-specific fixed kernel versions and apply them promptly once available.
• Reboot systems after kernel updates or confirm that a vendor-supported live patch has been applied successfully.
• Until patching is complete, rate-limit or restrict untrusted traffic to services that heavily exercise kernel cryptographic operations.
• Review recent kernel logs for crashes, oops traces, or warnings involving pcrypt, padata, AEAD, or crypto completion callbacks.
• Ensure critical systems have failover capacity because exploitation primarily affects availability.
• Track the vulnerability even though it is not currently in CISA KEV and has low EPSS; availability-only kernel bugs can become operationally significant if reliable trigger conditions are found.