From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 0D88543D4E9; Tue, 16 Jun 2026 17:00:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781629232; cv=none; b=KjYsNyuj6d7KmlcuJ/zONQvJCsbN+6B23SgdMrD+OxXsxi3ZxOBI0lqdR3zNL9nZIG/c8rfydZwzvgAmSpplZNcMaurEmU1Ux+URP/nSUqQrocT2lj6YgfOb72miSVfwLIn/c6vQhNTJP5SQhhfESNANAkf4HBI2kpiqQJe+SKo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781629232; c=relaxed/simple; bh=yp55iwdPIWMjaF27TFt3tQJgcZe84HOXiI2lX0tiiGA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NLsM6KOb1b8J93rMw2RbxVGFhhJOIKRSsknSAdYeIHPIT3n96M/sAb71dbHUNbNcDsB2Y0TaItsfx7G/UUX6qPRlyzch95xmX4gX56UCj2/DIZbSpfUvP+V7hmyLQJ9gb32BmBrF8VAJD9AI2zLR/cIK+OBlR4KSuXXMlEZcoNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=sLNZCm/7; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="sLNZCm/7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10B0C1F000E9; Tue, 16 Jun 2026 17:00:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1781629230; bh=kyakmwDjRh/U0MdGlLxxLU2451OutEdxJIEC27TzafA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=sLNZCm/72hG470kO1NU4GRrkutkziLN+vF0Vfv5dM9O+JOiwCvWV6z+yID3NLV6Jy 6+ZMpiWF6Svbrm8If2gkd5GSXUdGVtUFmcmZmqqZiqESvjMTy8jTPOapMdKYiqKyMR Es307YFQhXuvB1JDsd+hplPC0LJiq+QSQv3XsUWY= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Yizhou Zhao , Yuxiang Yang , Ao Wang , Xuewei Feng , Qi Li , Ke Xu , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.6 245/452] net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr Date: Tue, 16 Jun 2026 20:27:52 +0530 Message-ID: <20260616145130.537354661@linuxfoundation.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260616145117.796205997@linuxfoundation.org> References: <20260616145117.796205997@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.6-stable review patch. If anyone has any objections, please let me know. ------------------ From: Yizhou Zhao [ Upstream commit 7561c7fbc694308da73300f036719e63e42bf0b4 ] In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration. Fixes: febf018d2234 ("net/802: Implement Multiple Registration Protocol (MRP)") Reported-by: Yizhou Zhao Reported-by: Yuxiang Yang Reported-by: Ao Wang Reported-by: Xuewei Feng Reported-by: Qi Li Reported-by: Ke Xu Signed-off-by: Yizhou Zhao Link: https://patch.msgid.link/20260603060016.21522-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- net/802/mrp.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/802/mrp.c b/net/802/mrp.c index eafc21ecc287d9..a58e697e182a8f 100644 --- a/net/802/mrp.c +++ b/net/802/mrp.c @@ -702,6 +702,12 @@ static int mrp_pdu_parse_vecattr(struct mrp_applicant *app, valen = be16_to_cpu(get_unaligned(&mrp_cb(skb)->vah->lenflags) & MRP_VECATTR_HDR_LEN_MASK); + /* If valen is 0, only a LeaveAllEvent is present; FirstValue and + * Vector fields are absent per IEEE 802.1ak. + */ + if (valen == 0) + return 0; + /* The VectorAttribute structure in a PDU carries event information * about one or more attributes having consecutive values. Only the * value for the first attribute is contained in the structure. So @@ -752,6 +758,9 @@ static int mrp_pdu_parse_vecattr(struct mrp_applicant *app, vaevents %= __MRP_VECATTR_EVENT_MAX; vaevent = vaevents; mrp_pdu_parse_vecattr_event(app, skb, vaevent); + valen--; + mrp_attrvalue_inc(mrp_cb(skb)->attrvalue, + mrp_cb(skb)->mh->attrlen); } return 0; } -- 2.53.0