From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 540EAC433F5 for ; Wed, 2 Mar 2022 05:46:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239662AbiCBFr0 (ORCPT ); Wed, 2 Mar 2022 00:47:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52402 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233570AbiCBFrQ (ORCPT ); Wed, 2 Mar 2022 00:47:16 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F2E3B18A2; Tue, 1 Mar 2022 21:46:34 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id i11so719764eda.9; Tue, 01 Mar 2022 21:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ju1hFzCBSx147XTyPzHG3qmNTxLyCXpzXti14uOg3Zw=; b=XQF+mq2xUo6VNixetWdZ1ah04YUZjzhSzra/CYRofSGJDE9oyqxQuOsZ2aUlKxVCUK upIwsYaFU/7tAgmruY53YzGBr+StWr+B9KHUo9cqkRL2cuHRfwHwTcy82cYaMpl3HTpH P0BG3FHsuxSd/Xkrhm9wVVh9j+nwICAzyorT1NVBqF+eAPZrKpQQvMjr1olL9YgtjdbQ bdurXInJVclLC4K5jxGfbX3AZjf5gxXCwr7kPEaHMMIRz9I8KgpAFaQl1J0Ja5HB4smK OeXCLZCc11TNtROxRT6zvHWmHwF7yvMErvmyyxY3sSj3vMvOHY0DSlRA2YuUhN3HC0q1 Lzeg== 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=ju1hFzCBSx147XTyPzHG3qmNTxLyCXpzXti14uOg3Zw=; b=7v9W0JwB7zNHw0abOWM1d45u2mJsIsQqElN9/pZ9wZCec0fSHKOaXHLMri5vtxxxCk YOKYindtSjJMC84gIN7Ijjuvu1C+brhhTk4tcjS70Vl5UhNIczy/XJ7hsqgehUmYzaOc 014ek/oEVDFKIZR6dYTM5I7CbeOR1L6+3A6ML1EJUfuVuh34iF6PQcOfPG/61m+FcJuG qKs7eMqTHQlwLaUgohH5SM+ZwTnjyFwuc2Nl4Hf3xpqXkIDoHrBEOBqJa52AyK9w1gTP ikZ4I2jnXpJRw+Nv12JSSEPukSfNGmYYZ+QKwB2VsP6uep6ZTQKxvvyfa538Eup2xS4s 7wEA== X-Gm-Message-State: AOAM530opk/+Dg9YusxLR5HSf3ewimchcJDrS2jjicrK3h1qEMTnle2L M+XnkT8I1pF/p1KHnTXO4R99SKNlC3nMuNiT95lUoA8ERt0= X-Google-Smtp-Source: ABdhPJytECZlniE35uFfJSbPDZN0wge61h9/VBUAoayESw7OZkGGA6NQylxJFClTJ/9x3nWvWshmwHeuXwBl7OsJPYk= X-Received: by 2002:a05:6402:5304:b0:413:8a0c:c54a with SMTP id eo4-20020a056402530400b004138a0cc54amr19691262edb.172.1646199992679; Tue, 01 Mar 2022 21:46:32 -0800 (PST) MIME-Version: 1.0 References: <20220227134009.1298488-1-dzm91@hust.edu.cn> In-Reply-To: From: Dongliang Mu Date: Wed, 2 Mar 2022 13:46:04 +0800 Message-ID: Subject: Re: [PATCH] bpf: cgroup: remove WARN_ON at bpf_cgroup_link_release To: Daniel Borkmann Cc: Dongliang Mu , Alexei Starovoitov , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , syzkaller , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 2, 2022 at 12:28 AM Daniel Borkmann wrote: > > On 2/27/22 2:40 PM, Dongliang Mu wrote: > > From: Dongliang Mu > > > > When syzkaller injects fault into memory allocation at > > bpf_prog_array_alloc, the kernel encounters a memory failure and > > returns non-zero, thus leading to one WARN_ON at > > bpf_cgroup_link_release. The stack trace is as follows: > > > > __kmalloc+0x7e/0x3d0 > > bpf_prog_array_alloc+0x4f/0x60 > > compute_effective_progs+0x132/0x580 > > ? __sanitizer_cov_trace_pc+0x1a/0x40 > > update_effective_progs+0x5e/0x260 > > __cgroup_bpf_detach+0x293/0x760 > > bpf_cgroup_link_release+0xad/0x400 > > bpf_link_free+0xca/0x190 > > bpf_link_put+0x161/0x1b0 > > bpf_link_release+0x33/0x40 > > __fput+0x286/0x9f0 > > > > Fix this by removing the WARN_ON for __cgroup_bpf_detach. > > > > Reported-by: syzkaller > > Signed-off-by: Dongliang Mu > > --- > > kernel/bpf/cgroup.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c > > index 514b4681a90a..fdbdcee6c9fa 100644 > > --- a/kernel/bpf/cgroup.c > > +++ b/kernel/bpf/cgroup.c > > @@ -896,8 +896,8 @@ static void bpf_cgroup_link_release(struct bpf_link *link) > > return; > > } > > > > - WARN_ON(__cgroup_bpf_detach(cg_link->cgroup, NULL, cg_link, > > - cg_link->type)); > > + __cgroup_bpf_detach(cg_link->cgroup, NULL, cg_link, > > + cg_link->type); > > "Fixing" by removing WARN_ON is just papering over the issue which in this case as > mentioned is allocation failure on detach/teardown when allocating and recomputing > effective prog arrays.. Hi Daniel, you're right. This is not a good fix, any idea to fix the underlying bug perfectly? > > > cg = cg_link->cgroup; > > cg_link->cgroup = NULL; > > >