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

CVSS 5.5CVE-2022-50445Kernel, userspace & hypervisorcurated

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

https://git.kernel.org/stable/c/7d98b26684cb2390729525b341ea099f0badbe18 https://git.kernel.org/stable/c/f520075da484306bbb8425afd2c42404ba74816f https://nvd.nist.gov/vuln/detail/CVE-2022-50445

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.