Received: by 2002:a5d:925a:0:0:0:0:0 with SMTP id e26csp1167014iol; Fri, 10 Jun 2022 01:31:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkOUl+zI0kzG82fWbtwb2pkO7MlSSa/a7Ztp63iDm9fuajG7C5o7GuEhsBNhGX3xURORZI X-Received: by 2002:a17:907:7f8f:b0:711:623e:b344 with SMTP id qk15-20020a1709077f8f00b00711623eb344mr12147610ejc.230.1654849881219; Fri, 10 Jun 2022 01:31:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654849881; cv=none; d=google.com; s=arc-20160816; b=qe0ORnRoYNAEUqluAAanRqBuKmfZVkufUD6YgnZuilRWOz1rzWToCTOdF8nUk/XQgw 4ji+vXp4eSdMsTstRQAZfX7CHada5039zPCmkZXuO7RdziG4neYLFEoJO3OAeEDhpboh v4g09yEwvAiQsIMAkQK9yMSyipcP7HBD3Fj0XgHeQUMWiqyNO8tALM6j8nQ+3ppt9nM9 u75QhiFu3gfgc0FaMczGSEHwXTjG4NxmSpaIrKQykSjjMQOoHl22yxdpv0xXEk1GAd14 H0qqVxsUU/0fy5XOXHXu9MhCtf93o+pk7ecMQwvI0rRLuYzfIWQNkN4nQ5qigDRqc0HX MOHw== 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=7ePcvtrAfkDDMXBENLN5wUjeDPbbwzDe0oZvNvxzKMI=; b=QA/zVzz/oKgKMg37GAmUMa2Rx9XZHPTs9FE7V+mAdQ8K3I2YOniBPFpxqcfqQg3ymm v+Q7PrA3TAessnjG0ErDvzq+cSzQNzD0EIjfSfUJ2x0fZfc2b02NS/fvqBbo8KvDRoxZ v08RapNrq53w/Yhjj9DrjbCKj6GrkLxAOLK2tfxppye/POpqPiihGMjCP5qVHVMr89Mp RbNzvFBx3FytmuUHwLlTg4DQcfyz4WDH91YAIpEUI5gxwi/d6OlR5sE9MsvjFWXRqDjw ovaaTYCHRjqN0wxm1vTNZWHVqqYnu3o0c0XKcvnubyDXXShSFUwV1wiwJIkTjdtfcU9t t2jA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=iQ33QWZU; 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 hr3-20020a1709073f8300b006f39d88267dsi35778426ejc.690.2022.06.10.01.30.55; Fri, 10 Jun 2022 01:31:21 -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=iQ33QWZU; 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 S239667AbiFJHfd (ORCPT + 99 others); Fri, 10 Jun 2022 03:35:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243890AbiFJHfS (ORCPT ); Fri, 10 Jun 2022 03:35:18 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D51C012AB38 for ; Fri, 10 Jun 2022 00:35:16 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id r3so11478160ybr.6 for ; Fri, 10 Jun 2022 00:35:16 -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=7ePcvtrAfkDDMXBENLN5wUjeDPbbwzDe0oZvNvxzKMI=; b=iQ33QWZUIB+joeFDLf2jIZ39BXXh2xjPLpwX+yXbb6yVQYYr/hGUn97AjuBRUn5bzq MIBXrrIYvx+amFBeh2i4c0ZtPFJQKOmnKiJ+olioV+zq5N2EVcPdp97VpYEjRYhmaf/X 9zqr5NAzlWJzvUnLyshBIzzJ1GPEAfFFs/spS29v1myE0I1H/MjFlnhLA2QR/IibECz2 2oU2Vm0HgY1nlXFkBfpAu6wEugw/gstzWYQuows3fZWTw94iWyzi8YhiT/+J0avFdcAt lLb8vc6PpBZwhl6pdfHHnGSziPqJpn1cqYuBaAj2gZZZlccVu+Xh0kuWUWN9cqOBS2gg gFCw== 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=7ePcvtrAfkDDMXBENLN5wUjeDPbbwzDe0oZvNvxzKMI=; b=08E2iPqz4RqjMMn/Y7bCIP6mrgAOqNP1hHYqwStlZi9xEfDfEHTrlidH9VM2uwLE9m mvGoRybSa9H2lFe6SPwIBRB524gvOfjRCj/x2s0HWMhTiPpWz8yrk6NNqCJwanVogW1j crtPfK1rsFcZ6kIIXa1lT3/YdiubUsuLTWjPGBb+U30n7RWhvc7YKfs3CcaTPNv2k0lL V0yoPBL6ROHQKPmmuk602ZrF3XZcbkZ+6KNTG4ZzrVTyq/UpVoHNKE8d4ETMyp5EmBJ2 2mA3bLeW7VNXgexGUR+77LiJfPPPcoYjwk+WqrsZs0MNguavxqEv+p0z73wXAJmobn7m 9wDg== X-Gm-Message-State: AOAM533IQMCifPSKgccSGJc+050wO1gXOG47Ml+8gIQs1XTQKWCzI6fN PHvRUVmtrXQI4nlW9RBdBKhoYY04rWlbhy486hdoKQ== X-Received: by 2002:a25:504:0:b0:664:621d:1af4 with SMTP id 4-20020a250504000000b00664621d1af4mr1869951ybf.55.1654846515784; Fri, 10 Jun 2022 00:35:15 -0700 (PDT) MIME-Version: 1.0 References: <20220610070529.1623-1-zhudi2@huawei.com> In-Reply-To: From: Eric Dumazet Date: Fri, 10 Jun 2022 00:35:04 -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=unavailable 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:32 AM Eric Dumazet wrote: > > 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. > https://www.spinics.net/lists/netdev/msg777503.html > 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.