Re: [PATCH net-next 2/3] xfrm: Check inner packet family directly from skb_dst

[Sabrina Dubroca <sd@queasysnail.net>]

Some general notes:

 - ipsec patches should go through the ipsec/ipsec-next trees
   maintained by Steffen, not net/net-next directly, and use
   ipsec/ipsec-next in the subject prefix

 - this patch looks more like a bugfix, so it should target the ipsec
   tree and have a Fixes tag, instead of -next


2025-10-24, 05:31:36 +0300, Jianbo Liu wrote:
> In the output path, xfrm_dev_offload_ok and xfrm_get_inner_ipproto
> need to determine the protocol family of the inner packet (skb) before
> it gets encapsulated.
> 
> In xfrm_dev_offload_ok, the code checked x->inner_mode.family. This is
> incorrect because the state's true inner family might be specified in
> x->inner_mode_iaf.family (e.g., for tunnel mode).

I wouldn't say inner_mode_iaf.family is the "true" inner family. AFAIU
it's the other possible inner family for states that accept both
(I got that wrong in 91d8a53db219 ("xfrm: fix offloading of
cross-family tunnels")).

> In xfrm_get_inner_ipproto, the code checked x->outer_mode.family. This
> is also incorrect for tunnel mode, as the inner packet's family can be
> different from the outer header's family.
> 
> At both of these call sites, the skb variable holds the original inner
> packet. The most direct and reliable source of truth for its protocol
> family is its destination entry.

(the IP version would also work since it's in the same place for both
v4 and v6, but we have other uses of dst family in xfrm_output so it
should be fine)

> This patch fixes the issue by using
> skb_dst(skb)->ops->family to ensure protocol-specific headers are only
> accessed for the correct packet type.

Do you have an example of problematic setup? I didn't run into that
when I wrote 91d8a53db219.

-- 
Sabrina