From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [91.216.245.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 414AA2D7BF; Thu, 12 Sep 2024 06:03:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.216.245.30 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726121006; cv=none; b=VzJ2q1RMXY0UXluDmcY0DFTzlnE34D5MED/+DuJ0csb6yOj9iNaHdtxjRblfCPoNGE6yWdO611uapaabqRrPOLJP066mTiJvMmE2gbnrdwnJfh4wmmeFofLuSGvA0j0L58J+m3EscCXHCLqY6+AF/U6KxkJ5aha7CJ5w05Zxelc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1726121006; c=relaxed/simple; bh=uUUR3dtE4Kf4BXkkIJjOT8bDWswo2vCLF3eTJUx2644=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UyQVK59n4kIbNHuZQtpVkGddHwM7pLTBn0uCOaabgaQmYVbGVGS1hSN7HrI/A6qftuEgBFRwzsGMIzdpN0iq2k8ZP7GuGgH5ABSjBeOi7NVl/zDo9j0vaAN8tF3AWCQ2NDYJCaG51iivI8qAmcJM7YqIPSGqV7uICqCcjuiODGY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=strlen.de; spf=pass smtp.mailfrom=strlen.de; arc=none smtp.client-ip=91.216.245.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=strlen.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=strlen.de Received: from fw by Chamillionaire.breakpoint.cc with local (Exim 4.92) (envelope-from ) id 1socv5-0004rn-1K; Thu, 12 Sep 2024 08:03:07 +0200 Date: Thu, 12 Sep 2024 08:03:07 +0200 From: Florian Westphal To: En-Wei Wu 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 Message-ID: <20240912060307.GA18251@breakpoint.cc> References: <20240912033807.214238-1-en-wei.wu@canonical.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240912033807.214238-1-en-wei.wu@canonical.com> User-Agent: Mutt/1.10.1 (2018-07-13) En-Wei Wu 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 > --- > 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").