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 X-Spam-Level: X-Spam-Status: No, score=-13.2 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F9D6C64E7A for ; Tue, 1 Dec 2020 14:02:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E6785206A5 for ; Tue, 1 Dec 2020 14:02:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="QfxTVBHw" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E6785206A5 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 14A828D0005; Tue, 1 Dec 2020 09:02:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FBAA8D0001; Tue, 1 Dec 2020 09:02:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2ABD8D0005; Tue, 1 Dec 2020 09:02:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0241.hostedemail.com [216.40.44.241]) by kanga.kvack.org (Postfix) with ESMTP id D98208D0001 for ; Tue, 1 Dec 2020 09:02:51 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9B1C68249980 for ; Tue, 1 Dec 2020 14:02:51 +0000 (UTC) X-FDA: 77544879342.05.snake66_0a1734e273ab Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 76469180361A9 for ; Tue, 1 Dec 2020 14:02:51 +0000 (UTC) X-HE-Tag: snake66_0a1734e273ab X-Filterd-Recvd-Size: 5315 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Tue, 1 Dec 2020 14:02:50 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id u21so1110211qtw.11 for ; Tue, 01 Dec 2020 06:02:50 -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=DowCnJV0jJLxqPNhupVbMRSWGm+7uLhFQL0+P+g8v1E=; b=QfxTVBHwfLM/RTcmqP7qAGpmN8zoVJZN3uVb3RgA5Zx6sxjFNx9EX61ScUd2ihRp4m IdIO8X60HUdYF7hm3ofecC6QYqNf7d8muHij1SlMtLgd2Uu98smcn7rsSbLEuBI1yZaE JfXW2GDH+VbiCeMRXOq3jTxLpXlL75zY6XJi/8YsFmowA+aWUc2r0smb/Cud0R5TESMz UKTvjJFJ2Uzuo8VET0aad5u3KWz1pZDiJBa+PmpH7H3MsNS0eGRCFHTOV4G2j1Ie/uLg K+Ezx1gxo/gVWFntyD09ZoPaoloXkC8XQK+bR/543ckQKwNGj1sOvp73JdkaQx5vWrZX AnLA== 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=DowCnJV0jJLxqPNhupVbMRSWGm+7uLhFQL0+P+g8v1E=; b=V+jXOuyxaq3p7CouTy0HLxFcHOtg5N7B3ftuXu7Nqt6AmtNvBJPpgmTDiek++fNVEV TgHqzPGDs/hm3j91azn7xETtmI75E/s5j3Mr6sSd5J3wOSdp2SLzEpkLLoX2jSDZxj9U xrbHQGO+Mz3f6+W51cm2kRr/9+QQYptgpGBuZDR7n4SdrnS72wgA25ERCEOh/SKxDBKF pH6PPzB8GbeqZJRI+QOumjtUArimld649qiABYYvDsuHpMA5fW5ChECb2qjlz4ztn1P1 wbTjJHAvm9J4B/wGD9n8YeF+5ynvQYuBU9eSnpqaUOqc+uFJ3NRO0ULYVcjo7jKwO8jj yGkQ== X-Gm-Message-State: AOAM530yhDGaMRD9OCuyKEAVfEVwuSF61hy82S5mc20jQqchCobvWlGC S6IgQR5UVuUiKwq2jb4bhGEDFQRcIfhcY43J+ci9jQ== X-Google-Smtp-Source: ABdhPJxVr8e6IHqhxlpV/01xGGsXjC2Dt2bzhkooYsHv2mXQAPjcqkx/kLcjhAP7zSaTMnzLAHC47gA77xRhDBnFRuo= X-Received: by 2002:aed:2664:: with SMTP id z91mr2947243qtc.290.1606831369999; Tue, 01 Dec 2020 06:02:49 -0800 (PST) MIME-Version: 1.0 References: <20200924040152.30851-1-walter-zh.wu@mediatek.com> <87h7rfi8pn.fsf@nanos.tec.linutronix.de> <1606821422.6563.10.camel@mtksdccf07> In-Reply-To: <1606821422.6563.10.camel@mtksdccf07> From: Dmitry Vyukov Date: Tue, 1 Dec 2020 15:02:38 +0100 Message-ID: Subject: Re: [PATCH v4 0/6] kasan: add workqueue and timer stack for generic KASAN To: Walter Wu Cc: Thomas Gleixner , Andrew Morton , John Stultz , Stephen Boyd , Tejun Heo , Lai Jiangshan , Marco Elver , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Matthias Brugger , kasan-dev , Linux-MM , LKML , Linux ARM , wsd_upstream , linux-mediatek@lists.infradead.org Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Dec 1, 2020 at 12:17 PM Walter Wu wrote: > > Hi Dmitry, > > On Tue, 2020-12-01 at 08:59 +0100, 'Dmitry Vyukov' via kasan-dev wrote: > > On Wed, Sep 30, 2020 at 5:29 PM Thomas Gleixner wrote: > > > > > > On Thu, Sep 24 2020 at 12:01, Walter Wu wrote: > > > > Syzbot reports many UAF issues for workqueue or timer, see [1] and [2]. > > > > In some of these access/allocation happened in process_one_work(), > > > > we see the free stack is useless in KASAN report, it doesn't help > > > > programmers to solve UAF on workqueue. The same may stand for times. > > > > > > > > This patchset improves KASAN reports by making them to have workqueue > > > > queueing stack and timer stack information. It is useful for programmers > > > > to solve use-after-free or double-free memory issue. > > > > > > > > Generic KASAN also records the last two workqueue and timer stacks and > > > > prints them in KASAN report. It is only suitable for generic KASAN. > > > > Walter, did you mail v5? > > Checking statuses of KASAN issues and this seems to be not in linux-next. > > > > Sorry for the delay in responding to this patch. I'm busy these few > months, so that suspend processing it. > Yes, I will send it next week. But v4 need to confirm the timer stack is > useful. I haven't found an example. Do you have some suggestion about > timer? Good question. We had some use-after-free's what mention call_timer_fn: https://groups.google.com/g/syzkaller-bugs/search?q=%22kasan%22%20%22use-after-free%22%20%22expire_timers%22%20%22call_timer_fn%22%20 In the reports I checked call_timer_fn appears in the "access" stack rather in the "free" stack. Looking at these reports I cannot conclude that do_init_timer stack would be useful. I am mildly leaning towards not memorizing do_init_timer stack for now (until we have clear use cases) as the number of aux stacks is very limited (2).