Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4195853pxb; Tue, 2 Mar 2021 08:54:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4G+LRPfjkwJPZS8mSzVkaxqVI8/YCtc82zVJJeZZa6+xkYLd8SAhKktNGAequHGCrVjjx X-Received: by 2002:a17:906:fcb2:: with SMTP id qw18mr4671755ejb.434.1614704051574; Tue, 02 Mar 2021 08:54:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614704051; cv=none; d=google.com; s=arc-20160816; b=At/tqfq9ozGtADq6dN1TWGiuU/Ca8CzEYC1jqB/sG1ayAV6v2qhKxwqKoZbfYK0J02 mqpeB6F23sKL2z5CiQomz05BxD3NhdDO2mNAxH6eELVpuGl8pDOfX77/R5t0RzcwnsV3 VvteC33I8ApSJ58+J65TC9fRUMe1j0tFrTT1BULzjD7DK3ZG4PIdHAQ9SOYcFTN3QPuP ftCuP76UmXPPIf0dYZM7NtffpX/jurZxVMvGAzfUNJLuL6hC+6lFxYzcSbIYSTgY0YHR K2dMW8GyQmVQkOWK/FuKbI9s1D7wLG8F4iXy4Tbmdl3617EfVWyPBgO+2jXsiXMh8Upo 17xA== 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=ZRRNElgGOrQy90lAfZacJe2AKjVRmRS8fPPCyjr3PWQ=; b=ZXaYgAsMIf6EHKLQBA4Gxcu9i/rcQNkyYpQy/j8vTX440YDvPzDNuT1QGwFvwhCYv2 eGE9xLTKhUIMfFT6gZ9Kn4RePeDLpVIXCergh9UUMmN52iqHCdcS+5vLEwLjHmoS0nnU aYEkCfF6f7IodhupXklURo30UX7+CQf4sCbGlzsEqiNz3fPht5POONRMROH5RIKCaOtX iFC5y3b375kfTKI6LljmSb6a7JVI3SsR/uPMj+P8iMZ3iyFP247YkR18AHj0r13LlkJq ANTcZKLXNrKWwRhepmncJ34J8jyb4QUCIbEwgaA0Dk/t1a0idlT/RPxmizQPoa4lWEva rV5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=HgcLlGlE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hr33si13992066ejc.653.2021.03.02.08.53.47; Tue, 02 Mar 2021 08:54:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=HgcLlGlE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1574138AbhCBD3U (ORCPT + 99 others); Mon, 1 Mar 2021 22:29:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239789AbhCAUnx (ORCPT ); Mon, 1 Mar 2021 15:43:53 -0500 Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 804D7C061756 for ; Mon, 1 Mar 2021 12:43:12 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id s15so13143682qtq.0 for ; Mon, 01 Mar 2021 12:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZRRNElgGOrQy90lAfZacJe2AKjVRmRS8fPPCyjr3PWQ=; b=HgcLlGlEVYJ2DUAOt8BTHoX8moTnPbkbi5TLbHhaOzSqYCfAt4OCr3CbyWdoN3/rAr DX5+84PF+iK0J+wr/W9wXk2he5yiS0nA5OQtNqynOx4mCBX3ff4PNF+hlkDXS6+EOxX+ 3Oevsrmnauh8mSXX2eCEL8Fp4vlZFYVZsvywGIP+ijHykkOx9FtSxzWvwi7fuL0keSML VJe9tjGnUpoz5cgtYiV5F/RlQNhx6iSaM1RF/IKB0vYhzM4WvSdcAOMF8jTU7KpnaT2E 8SajaOCpvErUrDlk7L8RtZafk37CxCOmazGfu1TGZjMsLZ6twfJVfqqW8U+f3aZTxMBE QEnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZRRNElgGOrQy90lAfZacJe2AKjVRmRS8fPPCyjr3PWQ=; b=IZoyerrJ4+2KppJHlOlG8hR1u2OcG+vZSh8Xr3GgreWxftDRWZa0MOcHiGBG9rIrGj FZRz/zP2/VtdGyOugcAIq1L4xOtBtMVXzczoB/3/6gImtGILOm/GCbEhlr5gafxbeTya bnXvhLSiq5Y2lt1M5a505UmpAbmvm/7v8FeSMuLMDH96cXDn1d+40THAlcTcqLBI0e2q RRI/cmLJEtf69V/L8IuMG20RtEUT8ANLT9m3mfpAvF+fyyE1Jbw/SLN3tAg2V59KG6eG kLONCxG0QF1Qgr47QM6NYkjZ/KQlXdivKEVrIWVRxb0NYtBYIEpZly3+p0xnB6LbYNYp QXJA== X-Gm-Message-State: AOAM532Uc/X1evlgCLCT0BX4yvCDXW6WloL54Pwso5852Db3lrku7L+O IXQ4rB899iNbgrgQwGkUN8x6GYR/WiXbLNG39VSffg== X-Received: by 2002:ac8:6f3b:: with SMTP id i27mr3748150qtv.67.1614631391417; Mon, 01 Mar 2021 12:43:11 -0800 (PST) MIME-Version: 1.0 References: <000000000000911d3905b459824c@google.com> <000000000000e56a2605b616b2d9@google.com> In-Reply-To: From: Dmitry Vyukov Date: Mon, 1 Mar 2021 21:43:00 +0100 Message-ID: Subject: Re: memory leak in bpf To: Rustam Kovhaev Cc: syzbot , andrii@kernel.org, Alexei Starovoitov , bpf , Daniel Borkmann , John Fastabend , Martin KaFai Lau , KP Singh , LKML , netdev , Song Liu , syzkaller-bugs , Yonghong Song , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 1, 2021 at 9:39 PM Rustam Kovhaev wrote: > > On Mon, Mar 01, 2021 at 08:05:42PM +0100, Dmitry Vyukov wrote: > > On Mon, Mar 1, 2021 at 5:21 PM Rustam Kovhaev wrote: > > > > > > On Wed, Dec 09, 2020 at 10:58:10PM -0800, syzbot wrote: > > > > syzbot has found a reproducer for the following issue on: > > > > > > > > HEAD commit: a68a0262 mm/madvise: remove racy mm ownership check > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=11facf17500000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=4305fa9ea70c7a9f > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=f3694595248708227d35 > > > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=159a9613500000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11bf7123500000 > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > > Reported-by: syzbot+f3694595248708227d35@syzkaller.appspotmail.com > > > > > > > > Debian GNU/Linux 9 syzkaller ttyS0 > > > > Warning: Permanently added '10.128.0.9' (ECDSA) to the list of known hosts. > > > > executing program > > > > executing program > > > > executing program > > > > BUG: memory leak > > > > unreferenced object 0xffff88810efccc80 (size 64): > > > > comm "syz-executor334", pid 8460, jiffies 4294945724 (age 13.850s) > > > > hex dump (first 32 bytes): > > > > c0 cb 14 04 00 ea ff ff c0 c2 11 04 00 ea ff ff ................ > > > > c0 56 3f 04 00 ea ff ff 40 18 38 04 00 ea ff ff .V?.....@.8..... > > > > backtrace: > > > > [<0000000036ae98a7>] kmalloc_node include/linux/slab.h:575 [inline] > > > > [<0000000036ae98a7>] bpf_ringbuf_area_alloc kernel/bpf/ringbuf.c:94 [inline] > > > > [<0000000036ae98a7>] bpf_ringbuf_alloc kernel/bpf/ringbuf.c:135 [inline] > > > > [<0000000036ae98a7>] ringbuf_map_alloc kernel/bpf/ringbuf.c:183 [inline] > > > > [<0000000036ae98a7>] ringbuf_map_alloc+0x1be/0x410 kernel/bpf/ringbuf.c:150 > > > > [<00000000d2cb93ae>] find_and_alloc_map kernel/bpf/syscall.c:122 [inline] > > > > [<00000000d2cb93ae>] map_create kernel/bpf/syscall.c:825 [inline] > > > > [<00000000d2cb93ae>] __do_sys_bpf+0x7d0/0x30a0 kernel/bpf/syscall.c:4381 > > > > [<000000008feaf393>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > > > [<00000000e1f53cfd>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > > > > > > > > > i am pretty sure that this one is a false positive > > > the problem with reproducer is that it does not terminate all of the > > > child processes that it spawns > > > > > > i confirmed that it is a false positive by tracing __fput() and > > > bpf_map_release(), i ran reproducer, got kmemleak report, then i > > > manually killed those running leftover processes from reproducer and > > > then both functions were executed and memory was freed > > > > > > i am marking this one as: > > > #syz invalid > > > > Hi Rustam, > > > > Thanks for looking into this. > > > > I wonder how/where are these objects referenced? If they are not > > leaked and referenced somewhere, KMEMLEAK should not report them as > > leaks. > > So even if this is a false positive for BPF, this is a true positive > > bug and something to fix for KMEMLEAK ;) > > And syzbot will probably re-create this bug report soon as this still > > happens and is not a one-off thing. > > hi Dmitry, i haven't thought of it this way, but i guess you are right, > it is a kmemleak bug, ideally kmemleak should be aware that there are > still running processes holding references to bpf fd/anonymous inodes > which in their turn hold references to allocated bpf maps KMEMLEAK scans whole memory, so if there are pointers to the object anywhere in memory, KMEMLEAK should not report them as leaked. Running processes have no direct effect on KMEMLEAK logic. So the question is: where are these pointers to these objects? If we answer this, we can check how/why KMEMLEAK misses them. Are they mangled in some way?