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=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 DAC0DC4361B for ; Tue, 15 Dec 2020 03:09:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5F01822AAE for ; Tue, 15 Dec 2020 03:09:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5F01822AAE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DA8A88D001F; Mon, 14 Dec 2020 22:09:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D4A318D001C; Mon, 14 Dec 2020 22:09:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6EE78D001F; Mon, 14 Dec 2020 22:09:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0110.hostedemail.com [216.40.44.110]) by kanga.kvack.org (Postfix) with ESMTP id ADC4E8D001C for ; Mon, 14 Dec 2020 22:09:12 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 77CBC8249980 for ; Tue, 15 Dec 2020 03:09:12 +0000 (UTC) X-FDA: 77594035344.02.jelly25_231248027420 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id 5FCC910097AA0 for ; Tue, 15 Dec 2020 03:09:12 +0000 (UTC) X-HE-Tag: jelly25_231248027420 X-Filterd-Recvd-Size: 3820 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Dec 2020 03:09:11 +0000 (UTC) Date: Mon, 14 Dec 2020 19:09:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1608001751; bh=iFVfefYl6WXmZZrGWRpu19/az15QoJa3by/n7IVynUI=; h=From:To:Subject:In-Reply-To:From; b=0PWK9uZA9J5rCjopRraPEp0BOcHJXGjkzii5OW0gNQCMQ/0kJCYvoP2y/xtz44FZr R3D5c3hyYAJaJwddO35/qURmlLFcTZhd8fkc/dv8+y/3pc/Np9LYCaFE+4ePJWx5mF xMgjwMpxyeZHxvVXu9b6K+xlyBFFG8CmA3qrFAyc= From: Andrew Morton To: akpm@linux-foundation.org, andreyknvl@google.com, aryabinin@virtuozzo.com, corbet@lwn.net, dvyukov@google.com, elver@google.com, glider@google.com, jiangshanlai@gmail.com, linux-mm@kvack.org, matthias.bgg@gmail.com, mm-commits@vger.kernel.org, tj@kernel.org, torvalds@linux-foundation.org, walter-zh.wu@mediatek.com Subject: [patch 101/200] workqueue: kasan: record workqueue stack Message-ID: <20201215030909.JgNQqb-LN%akpm@linux-foundation.org> In-Reply-To: <20201214190237.a17b70ae14f129e2dca3d204@linux-foundation.org> User-Agent: s-nail v14.8.16 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: From: Walter Wu Subject: workqueue: kasan: record workqueue stack Patch series "kasan: add workqueue stack for generic KASAN", v5. Syzbot reports many UAF issues for workqueue, see [1]. 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 for workqueue issue. This patchset improves KASAN reports by making them to have workqueue queueing stack. It is useful for programmers to solve use-after-free or double-free memory issue. Generic KASAN also records the last two workqueue stacks and prints them in KASAN report. It is only suitable for generic KASAN. [1]https://groups.google.com/g/syzkaller-bugs/search?q=%22use-after-free%22+process_one_work [2]https://bugzilla.kernel.org/show_bug.cgi?id=198437 This patch (of 4): When analyzing use-after-free or double-free issue, recording the enqueuing work stacks is helpful to preserve usage history which potentially gives a hint about the affected code. For workqueue it has turned out to be useful to record the enqueuing work call stacks. Because user can see KASAN report to determine whether it is root cause. They don't need to enable debugobjects, but they have a chance to find out the root cause. Link: https://lkml.kernel.org/r/20201203022148.29754-1-walter-zh.wu@mediatek.com Link: https://lkml.kernel.org/r/20201203022442.30006-1-walter-zh.wu@mediatek.com Signed-off-by: Walter Wu Suggested-by: Marco Elver Acked-by: Marco Elver Acked-by: Tejun Heo Reviewed-by: Dmitry Vyukov Reviewed-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Lai Jiangshan Cc: Marco Elver Cc: Matthias Brugger Cc: Jonathan Corbet Signed-off-by: Andrew Morton --- kernel/workqueue.c | 3 +++ 1 file changed, 3 insertions(+) --- a/kernel/workqueue.c~workqueue-kasan-record-workqueue-stack +++ a/kernel/workqueue.c @@ -1327,6 +1327,9 @@ static void insert_work(struct pool_work { struct worker_pool *pool = pwq->pool; + /* record the work call stack in order to print it in KASAN reports */ + kasan_record_aux_stack(work); + /* we own @work, set data and link */ set_work_pwq(work, pwq, extra_flags); list_add_tail(&work->entry, head); _