lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4e528ea-f641-4ab9-bdde-5bd6beb65b8c@linux.dev>
Date: Tue, 28 Oct 2025 07:27:36 -0700
From: Zhu Yanjun <yanjun.zhu@...ux.dev>
To: Jianbo Liu <jianbol@...dia.com>, netdev@...r.kernel.org,
 davem@...emloft.net, kuba@...nel.org, steffen.klassert@...unet.com,
 sd@...asysnail.net
Cc: Cosmin Ratiu <cratiu@...dia.com>, Herbert Xu
 <herbert@...dor.apana.org.au>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 Leon Romanovsky <leon@...nel.org>, Raed Salem <raeds@...dia.com>
Subject: Re: [PATCH ipsec v3 1/2] xfrm: Check inner packet family directly
 from skb_dst


在 2025/10/27 19:22, Jianbo Liu 写道:
> 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
> unreliable because, for states handling both IPv4 and IPv6, the
> relevant inner family could be either x->inner_mode.family or
> x->inner_mode_iaf.family. Checking only the former can lead to a
> mismatch with the actual packet being processed.
>
> 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. 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.
>
> Fixes: 91d8a53db219 ("xfrm: fix offloading of cross-family tunnels")
> Fixes: 45a98ef4922d ("net/xfrm: IPsec tunnel mode fix inner_ipproto setting in sec_path")
> Signed-off-by: Jianbo Liu <jianbol@...dia.com>
> Reviewed-by: Cosmin Ratiu <cratiu@...dia.com>

Thanks a lot. I am fine with this.

Reviewed-by: Zhu Yanjun <yanjun.zhu@...ux.dev>

Zhu Yanjun

> ---
> V2:
>   - Change subject prefix, and send to "ipsec".
>   - Update commit msg.
>   - Add Fixes tag.
>
>   net/xfrm/xfrm_device.c | 2 +-
>   net/xfrm/xfrm_output.c | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/xfrm/xfrm_device.c b/net/xfrm/xfrm_device.c
> index 44b9de6e4e77..52ae0e034d29 100644
> --- a/net/xfrm/xfrm_device.c
> +++ b/net/xfrm/xfrm_device.c
> @@ -438,7 +438,7 @@ bool xfrm_dev_offload_ok(struct sk_buff *skb, struct xfrm_state *x)
>   
>   	check_tunnel_size = x->xso.type == XFRM_DEV_OFFLOAD_PACKET &&
>   			    x->props.mode == XFRM_MODE_TUNNEL;
> -	switch (x->inner_mode.family) {
> +	switch (skb_dst(skb)->ops->family) {
>   	case AF_INET:
>   		/* Check for IPv4 options */
>   		if (ip_hdr(skb)->ihl != 5)
> diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
> index 9077730ff7d0..a98b5bf55ac3 100644
> --- a/net/xfrm/xfrm_output.c
> +++ b/net/xfrm/xfrm_output.c
> @@ -698,7 +698,7 @@ static void xfrm_get_inner_ipproto(struct sk_buff *skb, struct xfrm_state *x)
>   		return;
>   
>   	if (x->outer_mode.encap == XFRM_MODE_TUNNEL) {
> -		switch (x->outer_mode.family) {
> +		switch (skb_dst(skb)->ops->family) {
>   		case AF_INET:
>   			xo->inner_ipproto = ip_hdr(skb)->protocol;
>   			break;

-- 
Best Regards,
Yanjun.Zhu


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ