Linux kernel (net/xfrm): Transmitting a packet carrying a metadata dst (no dst

Impact

Transmitting a packet carrying a metadata dst (no dst->dev) through an xfrm interface dereferences a NULL device pointer in the policy lookup and oopses the kernel in the transmit path. On a node running an encrypted tenant overlay this is a crash triggered by ordinary forwarded traffic.

Who can reach it

Requires an xfrm interface in the path plus a packet whose dst is a metadata dst - produced by collect_md tunnels (VXLAN/Geneve in metadata mode) or BPF redirect, which is exactly how per-tenant overlays are wired. A tenant that can get such a packet onto the overlay reaches the oops; no device node or privilege inside the container is needed beyond sending traffic.

What to do

Boot a kernel carrying the linked stable commits (5.10.140 and later in the 5.10 series). Interim: avoid combining collect_md metadata tunnels with xfrm interfaces on the same path.

References