Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp6823376rwn; Tue, 13 Sep 2022 09:26:37 -0700 (PDT) X-Google-Smtp-Source: AA6agR6iibJDeEN3Dv23GGHX9n4vJvwdtzFzkYkO3MgZNv3Mnq5MaUpHopIGjCl6XPIcDKxdq1bJ X-Received: by 2002:a17:903:32c4:b0:178:5206:b396 with SMTP id i4-20020a17090332c400b001785206b396mr1507992plr.99.1663086397518; Tue, 13 Sep 2022 09:26:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663086397; cv=none; d=google.com; s=arc-20160816; b=BKJvBFp7oZYS1YCrE0+tBaLSCdkPQSR4tSLxzwdJTAUbF4NI89iT2uq0m6A0Z2dO4/ c5BS8CB+DVftTHQ0RcJwhEDBxWPTcKqBZIBaA8R2ckHBQZtrJ9CGZXXwcwKlzCEuW/YW umrg91aZ4Jac+pi9HvtxpzoDl2veXJ1X43B3dZZvwOvy9dXkk2NfQ0XT2hCPuvbBM1zF sJXXaN4k9I0IpQqOYNPJsEH4lju6B9GSJvZgyp3IRbyBjK3SOqZr5Rv1gOfzp1Wx5Svw VDC0OM9tkCjHg8/Kk2BwamfybHVyfjZbFcAbALlWaGK5ojB/x/ndYwNAfXvy9WYJ+8sF l49Q== 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=kPGCAle0TQa1LKHSd6xNbu6TPF4uH/qDN6p/KwlAoRM=; b=Wz5WVu41LXcVxvgIpxoxYvKiYsOIG7srx93KVccBMpnPPOi9EHrDlpbOlaneoBPJrg qjjL16b2dInFrpF8xicQZQQkuo0+X+eKlbG04NE9bA+qO68vLxjBLWvMpKulmSFeTVSL IDi7d2JxEfcegSBd0/hB8uS6P+P58SpSpJE9Pa2jeWENlWKqHH3Yv4+dXwTshMbXOV5u vcjYvFWOOh7WB5jkDLtaglJQeV/xBofmnnLwNeLen9aEE72NQyd5mzFkQ5ZMXSeJhoip /gl9Ygl/pU2JZbh5Hwh1zEEZtsKklhZel/kubNlUau5MEgIq4OX3KF7e8L51AeUD+nsQ KWuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=yVEGhrlN; 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 h21-20020a056a001a5500b0054289be8a17si9184132pfv.328.2022.09.13.09.26.25; Tue, 13 Sep 2022 09:26:37 -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=yVEGhrlN; 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 S236327AbiIMP0J (ORCPT + 99 others); Tue, 13 Sep 2022 11:26:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236212AbiIMPXx (ORCPT ); Tue, 13 Sep 2022 11:23:53 -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 E492F7C76D; Tue, 13 Sep 2022 07:37:29 -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 DBC4C614B2; Tue, 13 Sep 2022 14:37:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1B8EC433D6; Tue, 13 Sep 2022 14:37:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1663079845; bh=qp9sJ4HEq5Md2IUIQHJCUdCQwwxXTwpuwjFmU978NYs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yVEGhrlNMOkKBG4dbG+btZzkhZttbSvA3e1lAJl85Oed/lo3jlLz41XjBY3pjZVwm zYHBXk5uClUzS2m+40e4pc7Y9d/o4rky4uZylpqYE4axDcpY1j9A7U1wHLlIyRhwJP lb5cHgblIsM40nsqaZBSng8OgQKwkI/2YeeEc7Hs= 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.9 36/42] sch_sfb: Dont assume the skb is still around after enqueueing to child Date: Tue, 13 Sep 2022 16:08:07 +0200 Message-Id: <20220913140344.198422215@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220913140342.228397194@linuxfoundation.org> References: <20220913140342.228397194@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 bc176bd48c026..592189427a09f 100644 --- a/net/sched/sch_sfb.c +++ b/net/sched/sch_sfb.c @@ -137,15 +137,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