Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp6825156rwn; Tue, 13 Sep 2022 09:28:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR4XATlNZGcI2gyLEN8U1Ru6Jnw44MBCPfEL1SE/lGHiFPFB/MA3YMzXRLHgfgGmmwXpoLgz X-Received: by 2002:a65:5789:0:b0:41a:4a7c:635d with SMTP id b9-20020a655789000000b0041a4a7c635dmr27666626pgr.60.1663086488264; Tue, 13 Sep 2022 09:28:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663086488; cv=none; d=google.com; s=arc-20160816; b=RO9746WoE/6yssjTBtbqm8hgnsDiFtYjvUqdA1EfsiTuBqHVCKyYDvuWi2Yzksy4yo q3OiOnpGMiPV0dFCoO17qKSXZMJYBZZYSBwZ42fOzcpoe8TSgfzCead1X+QB9VrHMuqq BGo9Evv6yAGFMcG8/OKOu90gJUH9lGqaopD331M6jZSrwSXTFmyZ0kDiJ1+7sBAc+UVa x0vBykda64VCSq8Jk1D87KQnDoKdY6g2X1ImPBw3enxZuR/2H3UaHmzUuHVk0stlkoKI 2GJcK2UlOQ6EgCp7FRCu4A0/Xc6dg6rOga790f/DsvN6brt9slZO56wOAfmO4pQNKFap o3zQ== 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=LXYLOdxl4QuVi7VjlUoqqWKZyj3Qoru/2pnbp/XBorY=; b=Se7TXQ02yBUt3zJPdhkrtcqG7BcNd3X2dlmCKjMc1cM+ST1wJeZlhong+q6imkNzuR 6cSP5YB3iDA4cNC9IOt9yAQaC5ATxp3WpWv6Pde8lMSnaY//xOeAAao+Uv337HyFhMo8 rcrV9Pv7UTd2UTttHtCw47DkQxXiVtfmphclUXrb+JKJ5rcZjPk0haHLJ9kpjacXVBsi H6V/Q26ejOODmLdkmQVDNBRslBFh8nz3OAqqeFWFfqXGlMwATbKAkJ5sTw0db3mzHVjR K8Mi+AkZs5s6TvsaW4mYzZ4wyn9rP2Msykz4trMuuCJaFFOrS6a63DuFueYgm2XOR3XC 9STg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sQUMqmEj; 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 e24-20020a637458000000b004355fc90c39si13241193pgn.261.2022.09.13.09.27.53; Tue, 13 Sep 2022 09:28:08 -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=sQUMqmEj; 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 S233322AbiIMPEv (ORCPT + 99 others); Tue, 13 Sep 2022 11:04:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235030AbiIMPCO (ORCPT ); Tue, 13 Sep 2022 11:02:14 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52A07BC0; Tue, 13 Sep 2022 07:29:26 -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 ams.source.kernel.org (Postfix) with ESMTPS id 9F857B80F6F; Tue, 13 Sep 2022 14:29:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16850C433C1; Tue, 13 Sep 2022 14:29:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1663079344; bh=XZ7QZ5fLq/vpZtWqyZMpef7Tz7QP4R97XcrSYVDojN8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sQUMqmEjjX2eJ/M/i+YrmEvtcr1jhQ3AlEKUM4vbdsrpVsGpQxqSoallziT1iGIyU k+LDNACaezqEkDfBxcs7wY0Dc6mxtQY5FP3vL7i2uj7q7dxPpLeDColvGblK8ZOH9h Vt5YW+3wZGkrK3ODfzeL7ngJC6QTTHkpQwSdi7+I= 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 5.4 098/108] sch_sfb: Dont assume the skb is still around after enqueueing to child Date: Tue, 13 Sep 2022 16:07:09 +0200 Message-Id: <20220913140357.832371776@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220913140353.549108748@linuxfoundation.org> References: <20220913140353.549108748@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 4074c50ac3d73..085fe06da2a68 100644 --- a/net/sched/sch_sfb.c +++ b/net/sched/sch_sfb.c @@ -135,15 +135,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); } @@ -283,6 +283,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; @@ -399,11 +400,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