Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp6772389rwn; Tue, 13 Sep 2022 08:49:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR45meEPKJ8fhJ6gJuQrGHV4d6JOqqMTitkkQw9KMWogIsejke1jw43JiA22OQR/4cBP8e26 X-Received: by 2002:a17:907:72d6:b0:742:133b:42be with SMTP id du22-20020a17090772d600b00742133b42bemr21340072ejc.581.1663084192719; Tue, 13 Sep 2022 08:49:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663084192; cv=none; d=google.com; s=arc-20160816; b=yXLXdTIM6Kabd5MDGbXdyM9+kP1PpF7tHIS7mkWVLUgJw/cL7ElDeD8V6aEOS1v0sU nzP+yvo0/QnU/SHZ+5jjgf8H2tNitjhBCCPlcTrVpX5TpnK5n3CxWWpx57UefS0MqCK5 w/0XZovaTcWPdusBEG2O5c7djkBoDOBfo8HNdkJzA4ttyDLOoyCu126mNe0hJzwcufZR 2iqFqcNW9DF8iMytDVWztwF4dBRXpzkVAP6jUtdndBv6Zq9Hoaq+NoziFPzbgZDWDaLF 9Ap6eGg8uNiNkvHurtKG5iDlKEF2/4R2SS1x1DKOFeafIwxYWXJOi9Pf23SboyHm2Q1m nclg== 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=yNtyJEJ0GjDwr+Jy3NFtHLTwMCH9l3MARo5gRRBpfM0=; b=OAd/aLGttVr4GDbZSybFkAhmVFSSKnYvOxZDh2ybSCMC+A2lQEobTbjTs1dBOb1an+ fby2UQ7o8IgpSZ7WbXgs44JQl3PAdlqOS2R3fYFp2JFGbx+CFQUmxsi23uH1jAQJHXnh 0+51yjVDz7SpN2lQffUC4d+QBqkTvs/B5653AlfYyCWRSOHSGq1cifoUXsdYyf9wrFhC LyetObhDi4cVI7zYpx6GLQkaS8ae8496QQzWTMG8uZh5mM7v3jM8XSFHCPpYyAEixBv8 CcEo/6mOS+j83ubTzKPh+n6rQQmPdXAx+rryGwcB8LVHZzQ5s5U9OU0Yf/tEQZdz3fH5 1u3w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="Mwy/g3sJ"; 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 hb11-20020a170907160b00b0077e29d27c39si4788336ejc.5.2022.09.13.08.49.24; Tue, 13 Sep 2022 08:49:52 -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="Mwy/g3sJ"; 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 S231816AbiIMP1X (ORCPT + 99 others); Tue, 13 Sep 2022 11:27:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236167AbiIMPZH (ORCPT ); Tue, 13 Sep 2022 11:25:07 -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 001C57C774; Tue, 13 Sep 2022 07:38:15 -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 EA443B81011; Tue, 13 Sep 2022 14:35:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64CCDC433C1; Tue, 13 Sep 2022 14:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1663079752; bh=TOk6w4g1d0aPPj4nkG0hFr3f+mLeWKDO6aiVF7WjoPQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mwy/g3sJVvoOxyPUook1ANVGXC9yjc25WYo3pKDbEGDDshfcbnsaAGxK/OytUyloZ iOuyhfytH22eGjN5P7ufZM9VIa5/0fDnaeXlinTE9JxpXXIyr3F7afHX3zd2vmAl24 MVNNR8uvfq4zJDMiPoZD4mClNYTLGXWZ3V/0qguc= 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.14 52/61] sch_sfb: Dont assume the skb is still around after enqueueing to child Date: Tue, 13 Sep 2022 16:07:54 +0200 Message-Id: <20220913140349.058426942@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220913140346.422813036@linuxfoundation.org> References: <20220913140346.422813036@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 04f15e0aeaa8b..8f924defa98d0 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); } @@ -286,6 +286,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; @@ -402,11 +403,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