Linux kernel (net/xfrm): Transport-mode IPsec packets were reinjected in the same execution context instead of being

Impact

Transport-mode IPsec packets were reinjected in the same execution context instead of being handed to a workqueue, so a sustained stream of ESP traffic can keep a CPU inside the crypto path long enough for the watchdog to fire (soft lockup, CPU stuck 22s). On a node whose east-west traffic all rides IPsec, that is a stall every tenant on the box feels.

Who can reach it

Driven by traffic, not by a device node. Any peer on the fabric - or any tenant workload generating heavy traffic through an IPsec transport-mode SA - can push the node into the reinject loop. Conditional on transport-mode (not tunnel-mode) xfrm being configured, which is the common shape for node-to-node encryption on a flat cluster fabric.

What to do

Boot a kernel carrying the linked stable commits. Interim: prefer tunnel mode over transport mode for node-to-node SAs, or rate-limit per-tenant egress so a single workload cannot saturate the ESP path.

References