Linux kernel pcrypt: padata fallback leaves the parallel completion callback on the child request

Impact

pcrypt installs its padata completion handler on the child AEAD request before submitting it to padata. When padata_do_parallel() returns -EBUSY, pcrypt falls back to invoking the child AEAD directly but leaves that handler in place, so an asynchronous completion runs padata bookkeeping for a request that was never enrolled - kernel state touched on behalf of an object that does not exist in the parallel queue. The record does not spell out the end state, and the vendor-assigned score treats it as availability only: a host that panics or wedges in softirq context. This only matters on nodes where the pcrypt template is actually instantiated, in practice AEAD under IPsec on multi-core hosts; a stock headless GPU node with no IPsec never loads it, and there is no exposure there at all. Where it does apply, the cost is a whole node's worth of GPUs lost mid-job rather than a drain you scheduled.

Who can reach it

Whoever can push enough traffic through a pcrypt-wrapped AEAD - typically an IPsec tunnel terminating on the node - to drive padata into its -EBUSY path. The CVSS vector is network, no authentication, beyond whatever the tunnel itself requires. Unreachable if pcrypt is not in use on the host.

What to do

Take a stable kernel carrying the listed fix commits and reboot each affected node; there is no runtime toggle for the code path itself. As an interim mitigation, stop using the pcrypt template for the AEAD in question (configure the plain algorithm instead), which removes the path without a reboot. Nodes not using pcrypt need no action.

References

Related entries

• Linux kernel libceph: a monmap advertising zero monitors hits a BUG_ON and takes down the client nodeCVE-2026-68155 · Linux kernel libceph (ceph_monmap_decode, zero-monitor monmap)High
• Linux kernel libceph: NULL dereference in CRUSH locality lookup when a parent bucket's type name is missingCVE-2026-68157 · Linux kernel libceph (get_immediate_parent CRUSH type name lookup)High
• Linux kernel (net/tls): A remote peer sends a zero-length TLS 1.3 application_data record - which the RFC explicitlyCVE-2026-72330 · Linux kernel (net/tls)High
• Linux kernel (drivers/nvme/target): A client that completes the TLS handshake against the NVMe-oF TCP target and thenCVE-2026-74385 · Linux kernel (drivers/nvme/target)High
• Linux kernel (drivers/nvme/target): Every connection that dies partway through queue allocation on the NVMe-oF TCPCVE-2026-74386 · Linux kernel (drivers/nvme/target)High
• Linux kernel libiscsi: out-of-bounds read leaks stale connection data into the SCSI sense bufferCVE-2026-74557 · Linux kernel libiscsi (SCSI Response sense-data bounds check)High