From nobody Sun May 24 17:49:06 2026 Received: from out-12.smtp.spacemail.com (out-12.smtp.spacemail.com [198.54.127.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3DBC145FE0; Sun, 24 May 2026 11:53:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.54.127.83 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779623592; cv=none; b=Dz+ObL+zYeyL49WJT7NiCKiYOuZTO/JGcKMm0YLH4k8F8y3zM8fOQ7vTgNVtjI41kW/SeaOY6WdKkBRnLB9xXIVZfU7uJuVeeITGZE+Rv3M2W2/S0nSuEKqQs01qMIdEsKgylHNf6cLz/2G9MbxuHfXKSr4UvHY9LWAqeahjBAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779623592; c=relaxed/simple; bh=jpZM8/zLddTDsq5GlC6TnbfoQOrGlwYCgXANTpOTf3s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=u11lKiGl90+huAvomVr7CCesqnekinUTCmQle6YiR1Zg5hBXguJ2AmH7/9MoYjtz5qpn9xLk4siVKZrK+rNXbS6pTkVzTqNelnMsPZ46E3HRitVq0LyPCAC1GaQhP5auEd5KU5GoOBYasBQ1LZBUs33jArM2d+BO1JSvhsMS39g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rexion.ai; spf=pass smtp.mailfrom=rexion.ai; dkim=fail (0-bit key) header.d=rexion.ai header.i=@rexion.ai header.b=LQofYPbK reason="key not found in DNS"; arc=none smtp.client-ip=198.54.127.83 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rexion.ai Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rexion.ai Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=rexion.ai header.i=@rexion.ai header.b="LQofYPbK" Received: from Kyren (unknown [49.207.213.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.spacemail.com (Postfix) with ESMTPSA id 4gNcpT51RNz6tkK; Sun, 24 May 2026 11:53:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rexion.ai; s=spacemail; t=1779623588; bh=j7VFnmR8Q2imsbnf/iLbK4SfOgvuJSNYrz/bMqfO1ZA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LQofYPbKaoyo4c3Cs7rJ41Oma/8rPwklkdBzSB1aJPRVsOH/MFGpUOzY81JdNxMC2 exzk+/KUf5xL5ifCIuxxebcuLO+qZnQ0+gG1Y5TCfoDqHnD1dCD8e6g8b0CtDhtjw5 HsV4QcAyTBnb7nj90s6hUCrqqTviK5jnjeo8ySP8T7PNWbKZjhhwIk1/MqYiARqGr3 Tsj6G2Q9pKchZcFC7ArQWpNT9QuOESqIhn/hiUoMKxsCN2Rmp/l50WaEYyxnu1K420 rpAbkB1Ne3v2JkCna10AGyMZCV/Ggv+nfYN+mlqT9tCPmiqf01A2bd/kwrePrKsK2o Lnnbv7N+K0Bhg== From: Rahul To: "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Simon Horman , Alexander Aring , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Rahul Subject: [PATCH net v2] ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() Date: Sun, 24 May 2026 17:23:01 +0530 Message-ID: <20260524115301.905478-1-rc@rexion.ai> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260501164242.419cc17e@kernel.org> References: <20260501164242.419cc17e@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Envelope-From: rc@rexion.ai Content-Type: text/plain; charset="utf-8" ipv6_rpl_srh_decompress() computes: outhdr->hdrlen =3D (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >=3D 127 the result exceeds 255 and silently truncates. With n=3D127 (cmpri=3D15, cmpre=3D15, pad=3D0, hdrlen=3D16): (128 * 16) >> 3 =3D 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=3D0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=3D127 passes because 128 <=3D 255, yet hdrlen=3D256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen =3D (127 * 16) >> 3 =3D 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) =3D buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment. Fixes: 8610c7c6e3bd ("net: ipv6: add support for rpl sr exthdr") Signed-off-by: Rahul --- net/ipv6/exthdrs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c index 95558fd6f..35a02584f 100644 --- a/net/ipv6/exthdrs.c +++ b/net/ipv6/exthdrs.c @@ -543,7 +543,7 @@ static int ipv6_rpl_srh_rcv(struct sk_buff *skb) * unsigned char which is segments_left field. Should not be * higher than that. */ - if (r || (n + 1) > 255) { + if (r || (n + 1) > 127) { kfree_skb(skb); return -1; } --=20 2.54.0