From nobody Mon Jun 8 22:53:03 2026 Received: from out-03.smtp.spacemail.com (out-03.smtp.spacemail.com [63.250.43.88]) (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 C4889202C48; Mon, 25 May 2026 15:50:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=63.250.43.88 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779724204; cv=none; b=ucNoUhXByALI+lMAao5550Oo6goB8doN/VvCfrvtOwbBVHFWyhE+D7JIa7eoKAHkAvQ/WbtBW6oJkdTAuKmVOpBngAhibYwSCYlp+4lbWaEh1m/YY0FFk43vhvfC8YaL8vi6hBbI48K+yLRaoqXyxS986Bwas7Nm694qruhHTD8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779724204; c=relaxed/simple; bh=VqqZmXG4qtl7D3IZAXMvozh/f+EgC0MJjqisx7xBX+s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=gfqqlJB+wWE7xMwazbbmzRxfdvuIyQ+5sXDRmuibQG/n5Zjy/z7r96gMRDUmg83vzoxCrUW67gX4zFS6A06hW5wTiFRUXbZj9n7xGJh6ZLRPzNkPebXw2XwBV9i+XQO8/jdUeOfZ2sJctKBw+LYjiSMMhEmU1/4E0QAnHnsgIZg= 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=H8NCPbtv reason="key not found in DNS"; arc=none smtp.client-ip=63.250.43.88 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="H8NCPbtv" 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 4gPKpd0LZ3z6tkq; Mon, 25 May 2026 15:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rexion.ai; s=spacemail; t=1779723644; bh=JUefQ2N3Ya8tzjlBXDac0kjYXwjD9oX4C6Aq4ymYW6g=; h=From:To:Cc:Subject:Date:From; b=H8NCPbtvVoQjwTj/X8hHTcElicz38krPHUB6eudjt81115oHJ4R0yce5cjRSWPyy4 n2IKD+37r+YeyXt0/YZ7yQKr2MfOAFIQP4CSK71d6JqjcedjenYEBwgHMlO+qKQKA1 FOZsmrAJ7/93L9w1kt+C+u2Bt4ftzkESXGcemmUFrC+YyjaWtT0kWc7IVBk2vN7+U2 fBaTTTZL2bXUhxHFoA7uJKvH5svgiS4K4XeZ2mQQSwWOXYzal6c9RfO4qd0UOZaxMb zJu8p4+nEHXGn7QRwJdSpfcERS7vn+tQ+vs0qjWMC+qMLwQ+fvoyQcHGYTjBhOCame BOe6H1ky16wew== From: Rahul Chandelkar 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 Chandelkar Subject: [PATCH net v2] ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() Date: Mon, 25 May 2026 21:10:31 +0530 Message-ID: <20260525154031.2290876-1-rc@rexion.ai> X-Mailer: git-send-email 2.54.0 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 Chandelkar --- 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