Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp1146908iol; Fri, 10 Jun 2022 00:58:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwhIWjwDRPbgXJ0zJWFvEbYOg13Pciruxh0FqrA2knuWRNRLzAnkWrdCDrXPqdejrNhlx2F X-Received: by 2002:a05:6402:2995:b0:42a:843f:ac82 with SMTP id eq21-20020a056402299500b0042a843fac82mr49258013edb.370.1654847900261; Fri, 10 Jun 2022 00:58:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654847900; cv=none; d=google.com; s=arc-20160816; b=hKl5A+eFfuMcOVMWXkzzkiREVuM/fSCJoy+ZmmYyagKJgg8Xre3GXKkWCLI6gjsY2q mQ6gAEwez0+Yr+VWMWTKTqF9FTikDssfuYKl1VJO7+xPnrbBfqYDtsDK5n4YXNZhXJLG BzQ7P/AfDJMr3TDWO4DNBfxHtp3FTJGwEQNVqxVSF5sMBGIqfjPvmbbwYu0F1HjwbvO6 5QXLVhnpZddGQgvsEGmLUrp106P3y6xkW0kiqrBqVNYPpxmxhM41KfIN5qjOXwdq9S9e c0ay27gJQaq9+yRUXQ9taWa1FRjXNIrGo0IuwlEUC5MmYgH1x4F+usy48QSzFop+0Y3L XT6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VpciQYHvryj/PequWAT65fK8eJ0KET3ZyhRRjOWqX1M=; b=l4YahGIk+7eDQaAfRQwux0FuiI2Evay6lUcT45VKrd5CVA3WcATG++IQK8JgucSwGM AciqG6A2oB6t2lpTWwv+rILHMukFms3Ax0c5UTFEFxdDs0/SZUhhMl6938A23yh04jEU r7anpn5MA0MW0H6mRMFtOlnohsNx4MqaDPpFnRcJ05HrFOwDIKCOGq6k1MnDEZA/7715 We78xCJK/NeUDGOX52iE5d6tYAAkdH050HSnByXzB8ol5QGx+KRxz0AxSspO0n7x52zw QgkhTaAmYwaoiirGrcT7mS1RtADxnwsOxm5RQ1l8qyqT1SgsYfbecIA7X35gw/ZF/yu8 Bcaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b="UQ/yeNEK"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id js22-20020a17090797d600b00711ca5e5b3esi2936114ejc.638.2022.06.10.00.57.54; Fri, 10 Jun 2022 00:58:20 -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=@google.com header.s=20210112 header.b="UQ/yeNEK"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346973AbiFJHdM (ORCPT + 99 others); Fri, 10 Jun 2022 03:33:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346798AbiFJHcu (ORCPT ); Fri, 10 Jun 2022 03:32:50 -0400 Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F1C212C94C for ; Fri, 10 Jun 2022 00:32:32 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id y188so16162102ybe.11 for ; Fri, 10 Jun 2022 00:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VpciQYHvryj/PequWAT65fK8eJ0KET3ZyhRRjOWqX1M=; b=UQ/yeNEKOtigurLd3J5UurzMzK/E0NubjoHgaLV+IJcD/aIMXKfBefiPuvfEu1Xp94 oao/op3nyn/VBSVwZYQ9FboihtQcWlOGwGbhJEX3Ypq0CJDExUsCR726Oqua5Z8X+Bd3 klgenZZQ7M2aOLizpFGil8fRF5QP8nA4zixyH8sZ2X+Hi3OQTasZPW7XIjCxORtrUi7f j9LGi8hfxudJgV/noJCWT24jBloCNlc6+Hlt0bNWiZVrb8VGz9pw5PFUypzoEeV+A1hx rhpTqPtB0beClKdRNPHpqt/lW1DO6YlKlxpbAKi5bxLsB9Ab7cXnUo8B/CGc2k+33JqQ WBFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VpciQYHvryj/PequWAT65fK8eJ0KET3ZyhRRjOWqX1M=; b=LpcyehTfRezZ29oYCj4Y/UA8hly8DFmJqIC8ly3F9niJU5lzBrptVF7zWo3qxdR1u2 2fu9CZJILf3bD22A3KP0zhltc+B0O5SllCvLPRrVXIIIOKFmHxwYOQKRqD+kOtoJ/xXV BBshmQzCtD8nuJqWyW/nw7sxIPp5GPP0QP5faYvofiGsPTpl5dbeCfqzCqLClOOgOA2D 3Wzbaf8YmJLR7IwDF2AR69xsy0CNAEso/9gEjKbfyKOMfSv6d43rN/WcE+bfKXH2h5Os kXbsT/RU7fHEq44pri+ssMZp4NNBGwZbgfzXpqHjnrb5rY3kmgiaW2N5d4379bd2Mcaq p+Yg== X-Gm-Message-State: AOAM532uNFBY3WKoatT1wpDy37UhokIpH4dSYQZTCR4/9PLGomUp9o/Q ptmG9n+AqOXlTK2gBMUFv4sAmCwR84deFbEiV8Ho+A== X-Received: by 2002:a05:6902:c9:b0:641:1998:9764 with SMTP id i9-20020a05690200c900b0064119989764mr42673115ybs.427.1654846350939; Fri, 10 Jun 2022 00:32:30 -0700 (PDT) MIME-Version: 1.0 References: <20220610070529.1623-1-zhudi2@huawei.com> In-Reply-To: <20220610070529.1623-1-zhudi2@huawei.com> From: Eric Dumazet Date: Fri, 10 Jun 2022 00:32:19 -0700 Message-ID: Subject: Re: [PATCH] fq_codel: Discard problematic packets with pkt_len 0 To: Di Zhu Cc: Jamal Hadi Salim , Cong Wang , Jiri Pirko , David Miller , Jakub Kicinski , Paolo Abeni , netdev , LKML , rose.chen@huawei.com, syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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 On Fri, Jun 10, 2022 at 12:07 AM Di Zhu wrote: > > Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any > skbs, that is, the flow->head is null. > The root cause is that: when the first queued skb with pkt_len 0, backlogs > of the flow that this skb enqueued is still 0 and if sch->limit is set to > 0 then fq_codel_drop() will be called. At this point, the backlogs of all > flows are all 0, so flow with idx 0 is selected to drop, but this flow have > not any skbs. > skb with pkt_len 0 can break existing processing logic, so just discard > these invalid skbs. > > LINK: [1] https://syzkaller.appspot.com/bug?id=0b84da80c2917757915afa89f7738a9d16ec96c5 > > Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com > Signed-off-by: Di Zhu > --- > net/sched/sch_fq_codel.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c > index 839e1235db05..c0f82b7358e1 100644 > --- a/net/sched/sch_fq_codel.c > +++ b/net/sched/sch_fq_codel.c > @@ -191,6 +191,9 @@ static int fq_codel_enqueue(struct sk_buff *skb, struct Qdisc *sch, > unsigned int pkt_len; > bool memory_limited; > > + if (unlikely(!qdisc_pkt_len(skb))) > + return qdisc_drop(skb, sch, to_free); > + This has been discussed in the past. Feeding ndo_start_xmit() in hundreds of drivers with zero-length packets will crash anyway. We are not going to add such silly tests in all qdiscs, and then all ndo_start_xmit(), since qdiscs are not mandatory. Please instead fix BPF layer, instead of hundreds of drivers/qdiscs.