Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp6767478rwn; Tue, 13 Sep 2022 08:45:47 -0700 (PDT) X-Google-Smtp-Source: AA6agR7D2gyxfelC4yn2uV0+PBKRaoX77EqUpgWDz0nvpIvEHiOLDKRGHCFzqCMuBuXwr3inMwc5 X-Received: by 2002:a17:907:808:b0:730:54cc:b597 with SMTP id wv8-20020a170907080800b0073054ccb597mr22014625ejb.434.1663083947053; Tue, 13 Sep 2022 08:45:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663083947; cv=none; d=google.com; s=arc-20160816; b=lD0xV+TJ93m1pNP8IwhrAOnr8sgUsDpRZVlyRP0tI57M9ZosSW13FU18b7YIvGL/NX k860PgoyQHF4bYMlKEtPSTMAep4g/eJdFhADX1J9MF+jEcSE8KHSezO/iWIsBeuKAO9F zYDX3P4nftJ3WY5jeJqWOFAdj1VXy0uFAntmdQMIzuM5fwke5T2R0DFBMW7GHE1LDccq PYaXCCniIotCsf/T8WABB0y19lh9X1R5OPCLrUiYQ7rMNGsi4J+1LiRZEkWbxpkkRYli JvSA3YH5Q+OpUdat5L6GAbkh6PkvMu2lJfOpUVaIBCy5cxEpPfjmtv3Ct9nZEpADcKlP Axtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=O39s5jTgge5QaSdMfnnkf1A9S/zi/eo7j9LCa8LLGT8=; b=TI1q7jhry4RIMsU39LGwirptLnnURZ52R4WxcEVOuytbqhG6yy+wcmtloZ0wTxneqc x/hBgGFiwB6oTI/xsOCfmzgtpqY5zqcHldzNcNAF0E3O6qguQCcVJ7eTRnBNVmE4KBjz BDC2rIeJS3otbUdq1qpd8Y3Mu+xajjZNH+eNrRNpCrPG6C0BpLJ0Z0dSTgDimmvIZauu LEWTwzfR39c13QcP1KFSuQhL9uL5PS7DKcT0hG0JrffQuxi+VQKfbYTN61F0fR7U7cvV K0SX77vG613kiipEQuSBy1lQELEvb8DBU8Xf5WlX/CBgsrQo9DBjUnA/TLBqapCBCRmG EZuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ke9zG8ri; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gs16-20020a1709072d1000b0077c393f05e8si6215546ejc.750.2022.09.13.08.45.15; Tue, 13 Sep 2022 08:45:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ke9zG8ri; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235831AbiIMPRH (ORCPT + 99 others); Tue, 13 Sep 2022 11:17:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235909AbiIMPOJ (ORCPT ); Tue, 13 Sep 2022 11:14:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E7756AA18; Tue, 13 Sep 2022 07:33:43 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AA696614C1; Tue, 13 Sep 2022 14:33:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86F28C433D6; Tue, 13 Sep 2022 14:33:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1663079609; bh=H1D+QZ2N+wLEuEAv5V5d0q1lZVLlwm/5xn6mWBLYCTw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ke9zG8riVLmOdE9+1U4yXHn70KFEXeNQ3e1IyY5b1GIrOHvbTsY47lcsVO3nriwYC zuozjld4Y8mr9J2/RJNvPZ745N9rRdxQ1LwOVTHsODS7bd/0tDwxU5cU80902Vkn7X wkWf/Ba5n6LAVVXVb84QLFEadrvkwuFUjuihNoiI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , "David S. Miller" , Sasha Levin , zdi-disclosures@trendmicro.com Subject: [PATCH 4.19 66/79] sch_sfb: Dont assume the skb is still around after enqueueing to child Date: Tue, 13 Sep 2022 16:07:24 +0200 Message-Id: <20220913140352.078322905@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220913140348.835121645@linuxfoundation.org> References: <20220913140348.835121645@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Toke Høiland-Jørgensen [ Upstream commit 9efd23297cca530bb35e1848665805d3fcdd7889 ] The sch_sfb enqueue() routine assumes the skb is still alive after it has been enqueued into a child qdisc, using the data in the skb cb field in the increment_qlen() routine after enqueue. However, the skb may in fact have been freed, causing a use-after-free in this case. In particular, this happens if sch_cake is used as a child of sfb, and the GSO splitting mode of CAKE is enabled (in which case the skb will be split into segments and the original skb freed). Fix this by copying the sfb cb data to the stack before enqueueing the skb, and using this stack copy in increment_qlen() instead of the skb pointer itself. Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18231 Fixes: e13e02a3c68d ("net_sched: SFB flow scheduler") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/sched/sch_sfb.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/sched/sch_sfb.c b/net/sched/sch_sfb.c index 81d205acb1b6a..38cf065156951 100644 --- a/net/sched/sch_sfb.c +++ b/net/sched/sch_sfb.c @@ -139,15 +139,15 @@ static void increment_one_qlen(u32 sfbhash, u32 slot, struct sfb_sched_data *q) } } -static void increment_qlen(const struct sk_buff *skb, struct sfb_sched_data *q) +static void increment_qlen(const struct sfb_skb_cb *cb, struct sfb_sched_data *q) { u32 sfbhash; - sfbhash = sfb_hash(skb, 0); + sfbhash = cb->hashes[0]; if (sfbhash) increment_one_qlen(sfbhash, 0, q); - sfbhash = sfb_hash(skb, 1); + sfbhash = cb->hashes[1]; if (sfbhash) increment_one_qlen(sfbhash, 1, q); } @@ -287,6 +287,7 @@ static int sfb_enqueue(struct sk_buff *skb, struct Qdisc *sch, struct sfb_sched_data *q = qdisc_priv(sch); struct Qdisc *child = q->qdisc; struct tcf_proto *fl; + struct sfb_skb_cb cb; int i; u32 p_min = ~0; u32 minqlen = ~0; @@ -403,11 +404,12 @@ static int sfb_enqueue(struct sk_buff *skb, struct Qdisc *sch, } enqueue: + memcpy(&cb, sfb_skb_cb(skb), sizeof(cb)); ret = qdisc_enqueue(skb, child, to_free); if (likely(ret == NET_XMIT_SUCCESS)) { qdisc_qstats_backlog_inc(sch, skb); sch->q.qlen++; - increment_qlen(skb, q); + increment_qlen(&cb, q); } else if (net_xmit_drop_count(ret)) { q->stats.childdrop++; qdisc_qstats_drop(sch); -- 2.35.1