From: Florian Westphal <fw@strlen.de>
To: En-Wei Wu <en-wei.wu@canonical.com>
Cc: steffen.klassert@secunet.com, herbert@gondor.apana.org.au,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kai.heng.feng@canonical.com,
chia-lin.kao@canonical.com, anthony.wong@canonical.com,
kuan-ying.lee@canonical.com, chris.chiu@canonical.com
Subject: Re: [PATCH ipsec] xfrm: avoid using skb->mac_len to decide if mac header is shown
Date: Thu, 12 Sep 2024 08:03:07 +0200 [thread overview]
Message-ID: <20240912060307.GA18251@breakpoint.cc> (raw)
In-Reply-To: <20240912033807.214238-1-en-wei.wu@canonical.com>
En-Wei Wu <en-wei.wu@canonical.com> wrote:
> When we use Intel WWAN with xfrm, our system always hangs after
> browsing websites for a few seconds. The error message shows that
> it is a slab-out-of-bounds error:
>
> The reason is that the eth_hdr(skb) inside the if statement evaluated
> to an unexpected address with skb->mac_header = ~0U (indicating there
> is no MAC header). The unreliability of skb->mac_len causes the if
> statement to become true even if there is no MAC header inside the
> skb data buffer.
>
> Replace the skb->mac_len in the if statement with the more reliable macro
> skb_mac_header_was_set(skb) fixes this issue.
>
> Fixes: b3284df1c86f ("xfrm: remove input2 indirection from xfrm_mode")
No, that just moved code around.
> Signed-off-by: En-Wei Wu <en-wei.wu@canonical.com>
> ---
> net/xfrm/xfrm_input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> index 749e7eea99e4..93b261340105 100644
> --- a/net/xfrm/xfrm_input.c
> +++ b/net/xfrm/xfrm_input.c
> @@ -251,7 +251,7 @@ static int xfrm4_remove_tunnel_encap(struct xfrm_state *x, struct sk_buff *skb)
>
> skb_reset_network_header(skb);
> skb_mac_header_rebuild(skb);
> - if (skb->mac_len)
> + if (skb_mac_header_was_set(skb))
> eth_hdr(skb)->h_proto = skb->protocol;
I think you will need to check both, else you restore the bug fixed in
87cdf3148b11 ("xfrm: Verify MAC header exists before overwriting
eth_hdr(skb)->h_proto").
prev parent reply other threads:[~2024-09-12 6:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 3:38 [PATCH ipsec] xfrm: avoid using skb->mac_len to decide if mac header is shown En-Wei Wu
2024-09-12 6:03 ` Florian Westphal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240912060307.GA18251@breakpoint.cc \
--to=fw@strlen.de \
--cc=anthony.wong@canonical.com \
--cc=chia-lin.kao@canonical.com \
--cc=chris.chiu@canonical.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=en-wei.wu@canonical.com \
--cc=herbert@gondor.apana.org.au \
--cc=kai.heng.feng@canonical.com \
--cc=kuan-ying.lee@canonical.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=steffen.klassert@secunet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.