Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp8175053ybi; Thu, 6 Jun 2019 07:55:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRuG6iGp+YaWBcilz1lZImEYW7oju95B8veJq0SB008JBA9YHpNCd6ME62Y8raZr/QEBoQ X-Received: by 2002:a17:90a:bb94:: with SMTP id v20mr308490pjr.88.1559832912835; Thu, 06 Jun 2019 07:55:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559832912; cv=none; d=google.com; s=arc-20160816; b=g1uMWWyBqMWQd5tdlsuexWvgAiutsRy4h20OB7hE+525ECaskrEua1YeAvGox+P75r +AJIIWsyTEGPXPxOvXtFH81hnBB7nngdneY8VBqvctSknIW2ON1RwLicFEdmJ6kkGbAX H/2utOf0mdrCnGuF4c1FCKmkXf2S3eqYHZVifpz4pDEWwupkioBi121XCFmCloYfVCCR zvbknHMoAROzrX0twKdUiGlVEXx9fKNDZGx4JFFGPgO9hQtG/aIOK4DhLR3FZiR8bGsR jdOEg0biBr99Kmb05FAvZ0TlmfNfTfM+PLDImnlRwbxrlV8V28On7r9Jg/tknZlC6d/P uZ/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=dD702thkJa4xRC9FL35mAEmbp02pQamPCZ6/vuPpoAQ=; b=ch3IjfGd2coLTsK31xN5QY6z5R28krUc6f1K0WZJWaPLk+KCPcsqmPJuMEpbgQPtc+ NnHtVYC2ssrFSpMa/UwGKKu0CPpElxUxMy0IqRGcljY7IigS3NNHXV4llXQlvJu6Vgwd HRb31AizEUKYX4pRfEBXSZBVyVWjWT65LRpkliGWIrQKybwN/t52WgH04S2KWEG7qAGk gSGYvK49Q5ma35vZaEGkcAnas35sVSAB0C4/XxsTtGRc39sJ4DmG/V3UrS1xTTOJyXev YohhcxzhAHtZh2tNqMggCkPC/G3HlJ1oj38lqK9ADD/E6njDJtBmKICkOeTTca7UIB+0 XxTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h5si2020914pjs.96.2019.06.06.07.54.51; Thu, 06 Jun 2019 07:55:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727961AbfFFOym (ORCPT + 99 others); Thu, 6 Jun 2019 10:54:42 -0400 Received: from relay.sw.ru ([185.231.240.75]:36108 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727559AbfFFOym (ORCPT ); Thu, 6 Jun 2019 10:54:42 -0400 Received: from [172.16.25.169] by relay.sw.ru with esmtp (Exim 4.91) (envelope-from ) id 1hYtmX-0000ch-5P; Thu, 06 Jun 2019 17:54:21 +0300 Subject: Re: KASAN: use-after-free Read in unregister_shrinker To: Dmitry Vyukov Cc: "J. Bruce Fields" , syzbot , Andrew Morton , bfields@redhat.com, chris@chrisdown.name, Daniel Jordan , guro@fb.com, Johannes Weiner , Jeff Layton , laoar.shao@gmail.com, LKML , Linux-MM , linux-nfs@vger.kernel.org, Mel Gorman , Michal Hocko , Stephen Rothwell , syzkaller-bugs , yang.shi@linux.alibaba.com References: <0000000000005a4b99058a97f42e@google.com> <20190606131334.GA24822@fieldses.org> <275f77ad-1962-6a60-e60b-6b8845f12c34@virtuozzo.com> From: Kirill Tkhai Message-ID: <00ec828a-0dcb-ca70-e938-ca26a6a8b675@virtuozzo.com> Date: Thu, 6 Jun 2019 17:54:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On 06.06.2019 17:40, Dmitry Vyukov wrote: > On Thu, Jun 6, 2019 at 3:43 PM Kirill Tkhai wrote: >> >> On 06.06.2019 16:13, J. Bruce Fields wrote: >>> On Thu, Jun 06, 2019 at 10:47:43AM +0300, Kirill Tkhai wrote: >>>> This may be connected with that shrinker unregistering is forgotten on error path. >>> >>> I was wondering about that too. Seems like it would be hard to hit >>> reproduceably though: one of the later allocations would have to fail, >>> then later you'd have to create another namespace and this time have a >>> later module's init fail. >> >> Yes, it's had to bump into this in real life. >> >> AFAIU, syzbot triggers such the problem by using fault-injections >> on allocation places should_failslab()->should_fail(). It's possible >> to configure a specific slab, so the allocations will fail with >> requested probability. > > No fault injection was involved in triggering of this bug. > Fault injection is clearly visible in console log as "INJECTING > FAILURE at this stack track" splats and also for bugs with repros it > would be noted in the syzkaller repro as "fault_call": N. So somehow > this bug was triggered as is. > > But overall syzkaller can do better then the old probabilistic > injection. The probabilistic injection tend to both under-test what we > want to test and also crash some system services. syzkaller uses the > new "systematic fault injection" that allows to test specifically each > failure site separately in each syscall separately. Oho! Interesting. > All kernel testing systems should use it. Also in couple with KASAN, > KMEMLEAK, LOCKDEP. It's indispensable in finding kernel bugs.