From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 6C0C7209F43; Sat, 2 May 2026 08:43:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777711420; cv=none; b=j8rOvW8p9p/LsFRk/Q/q4OzTMA15PqyrmKlkuWERXkJEeoa0ULbazGiYsezCPJkjYBhIK54A0/2iFW6jhXayptrkD6tbmXDtfHK0NIaNigrIjpSGGJHekCp00nRhXsvD58XwyY7sngiMF5mCebA21HpPJKXx0mSdlauR3FJqMc0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777711420; c=relaxed/simple; bh=cGT2LsQdCuNfBjWP4h6E5RQfcN7GyBzIdyAZwXqCsII=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p8Xxo9hCAvBUceCmJcIdjJ7M8/LLbWJdldGQnCBKm7gRhFFitSK0iRG6uCtHzZZ/73eODjib+tVcrzEJyXXffVe3ObfRkfGMBVldcenNFgEPm9P+46acmsx8tZ1DO0vPDmz6NZ5WCxnzymAQr4VEFMUWwpNNklvZ0UvR4LZ8Xm4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=WHgcvyx8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="WHgcvyx8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C810C19425; Sat, 2 May 2026 08:43:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1777711420; bh=cGT2LsQdCuNfBjWP4h6E5RQfcN7GyBzIdyAZwXqCsII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WHgcvyx8/S1amLAK7e2Ztp3yr7HLWIs+4kJGxKENpajrxypdEsYBoIYC7UsSvcfNK SATUdZ3L7mqYn2PVaNY1aovGWzePgAdBL36FExXmdPhAv6vdigKZVzi9hyZFaF4P33 fMyuMjVxEbeski3JStShgMDFn66DjQVS8dhLFjqI= Date: Sat, 2 May 2026 10:42:58 +0200 From: Greg Kroah-Hartman To: Yuan Tan Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , David Ahern , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , stable Subject: Re: [PATCH net v3] ipv6: rpl: reserve mac_len headroom when recompressed SRH grows Message-ID: <2026050237-subheader-footsie-9f72@gregkh> References: <2026042133-gout-unvented-1bd9@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, May 02, 2026 at 01:36:18AM -0700, Yuan Tan wrote: > On Tue, Apr 21, 2026 at 6:16 AM Greg Kroah-Hartman > wrote: > > > > ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps > > the next segment into ipv6_hdr->daddr, recompresses, then pulls the old > > header and pushes the new one plus the IPv6 header back. The > > recompressed header can be larger than the received one when the swap > > reduces the common-prefix length the segments share with daddr (CmprI=0, > > CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). > > > > pskb_expand_head() was gated on segments_left == 0, so on earlier > > segments the push consumed unchecked headroom. Once skb_push() leaves > > fewer than skb->mac_len bytes in front of data, > > skb_mac_header_rebuild()'s call to: > > > > skb_set_mac_header(skb, -skb->mac_len); > > > > will store (data - head) - mac_len into the u16 mac_header field, which > > wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB > > past skb->head. > > > > A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two > > segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one > > pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. > > > > Fix this by expanding the head whenever the remaining room is less than > > the push size plus mac_len, and request that much extra so the rebuilt > > MAC header fits afterwards. > > > > Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") > > Cc: "David S. Miller" > > Cc: David Ahern > > Cc: Eric Dumazet > > Cc: Jakub Kicinski > > Cc: Paolo Abeni > > Cc: Simon Horman > > Cc: stable > > Reported-by: Anthropic > > Assisted-by: gkh_clanker_t1000 > > Signed-off-by: Greg Kroah-Hartman > > --- > > v3: - skb_postpull_rcsum() should not be changed, it's chdr NOT hdr, ugh > > Link to v2: https://lore.kernel.org/r/2026042158-sediment-elliptic-a954@gregkh > > > > v2: - fixed up if statement to actually work properly, and test it > > against a working poc (poc will be sent separately) > > Reworded the changelog and the subject to make more sense > > Link to v1: https://lore.kernel.org/r/2026042024-cabbie-gills-9371@gregkh > > > > net/ipv6/exthdrs.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c > > index 95558fd6f447..03cbce842c1a 100644 > > --- a/net/ipv6/exthdrs.c > > +++ b/net/ipv6/exthdrs.c > > @@ -491,6 +491,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb) > > struct net *net = dev_net(skb->dev); > > struct inet6_dev *idev; > > struct ipv6hdr *oldhdr; > > + unsigned int chdr_len; > > unsigned char *buf; > > int accept_rpl_seg; > > int i, err; > > @@ -592,8 +593,10 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb) > > skb_pull(skb, ((hdr->hdrlen + 1) << 3)); > > skb_postpull_rcsum(skb, oldhdr, > > sizeof(struct ipv6hdr) + ((hdr->hdrlen + 1) << 3)); > > - if (unlikely(!hdr->segments_left)) { > > - if (pskb_expand_head(skb, sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3), 0, > > + chdr_len = sizeof(struct ipv6hdr) + ((chdr->hdrlen + 1) << 3); > > + if (unlikely(!hdr->segments_left || > > + skb_headroom(skb) < chdr_len + skb->mac_len)) { > > + if (pskb_expand_head(skb, chdr_len + skb->mac_len, 0, > > GFP_ATOMIC)) { > > __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)), IPSTATS_MIB_OUTDISCARDS); > > kfree_skb(skb); > > @@ -603,7 +606,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb) > > > > oldhdr = ipv6_hdr(skb); > > } > > - skb_push(skb, ((chdr->hdrlen + 1) << 3) + sizeof(struct ipv6hdr)); > > + skb_push(skb, chdr_len); > > skb_reset_network_header(skb); > > skb_mac_header_rebuild(skb); > > skb_set_transport_header(skb, sizeof(struct ipv6hdr)); > > -- > > 2.53.0 > > > > I am happy to see this bug is finally fixed. > > However, it seems the Reported-by tag does not include our credit. > > We first submitted the security report and patch to > security@kernel.org on February 23, titled: > > [SECURITY] IPv6/RPL: 14-byte controllable OOB write via SRH len > overflow + skb_mac_header_rebuild() u16 wraparound > > [PATCH] ipv6: rpl: rebuild MAC+metadata safely when rewriting SRH > > We have aslo followed up and resent the patch several times, CCing all > relevant maintainers. > > Could our credit be added to the patch? > > Reported-by: Yuan Tan > Reported-by: Yifan Wu > Reported-by: Juefei Pu > Reported-by: Xin Liu > > I noticed this patch has already been merged into the mainline. Maybe > it's too late to amend this patch. Is there any other way to document > our reporting credit in the official records? Maybe in the stable > backport? Sorry, I made this patch based on a different report to me as is documented in this patch, and did not notice that it was the same thing as this one as I am drowning in reports. This happens at times, and we can't rewrite public git history as that's impossible to do, sorry about that. You have a public confirmation here that yes, you did report this same issue, and yes, you did submit a patch to resolve this, but it ended up being different from the one that was accepted. Which again, happens all the time, it's just the nature of development with a huge body of contributors. thanks, greg k-h