From patchwork Fri Apr 30 06:00:45 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 12232609 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=unavailable 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 D0FD8C43460 for ; Fri, 30 Apr 2021 06:01:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 82366613F8 for ; Fri, 30 Apr 2021 06:01:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82366613F8 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 C2FB5940038; Fri, 30 Apr 2021 02:01:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66766940047; Fri, 30 Apr 2021 02:01:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27F16940038; Fri, 30 Apr 2021 02:01:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0098.hostedemail.com [216.40.44.98]) by kanga.kvack.org (Postfix) with ESMTP id EA522940038 for ; Fri, 30 Apr 2021 02:01:47 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id AD27945AB for ; Fri, 30 Apr 2021 06:01:47 +0000 (UTC) X-FDA: 78087987054.09.5B128EA Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP id D89AD900115F for ; Fri, 30 Apr 2021 06:00:16 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 4A6AB6147E; Fri, 30 Apr 2021 06:00:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1619762446; bh=mRwLr0e8X+wSiQl3LIXYEs0Wa7hiH8VOxiNWAGA+BiQ=; h=Date:From:To:Subject:In-Reply-To:From; b=1DiD93kHRwzafgQvysrrOgOYbRCt8+cpqZPAmGkO6+GAhM7KaD+KQ4b18jSnmAsjE NZInkMylZa608zH74GUbjzetGkpeLdLrSo80yPnQHXKW+5QM1ot00j97D75wvjTXXs rMugj4hjMsUGIyFbvkqvuw4+Qy2sJ1W4o2wSYtyk= Date: Thu, 29 Apr 2021 23:00:45 -0700 From: Andrew Morton To: akpm@linux-foundation.org, andreyknvl@google.com, axboe@kernel.dk, dvyukov@google.com, glider@google.com, linux-mm@kvack.org, matthias.bgg@gmail.com, mm-commits@vger.kernel.org, oleg@redhat.com, ryabinin.a.a@gmail.com, torvalds@linux-foundation.org, walter-zh.wu@mediatek.com Subject: [patch 147/178] kasan: record task_work_add() call stack Message-ID: <20210430060045.EygxZbqmc%akpm@linux-foundation.org> In-Reply-To: <20210429225251.02b6386d21b69255b4f6c163@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D89AD900115F Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=1DiD93kH; dmarc=none; spf=pass (imf19.hostedemail.com: domain of akpm@linux-foundation.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Stat-Signature: ro1f1tz8x1qm9zesh9bxb4r3rrkgxt9z Received-SPF: none (linux-foundation.org>: No applicable sender policy available) receiver=imf19; identity=mailfrom; envelope-from=""; helo=mail.kernel.org; client-ip=198.145.29.99 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619762416-856411 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: kasan: record task_work_add() call stack Why record task_work_add() call stack? Syzbot reports many use-after-free issues for task_work, see [1]. After seeing the free stack and the current auxiliary stack, we think they are useless, we don't know where the work was registered. This work may be the free call stack, so we miss the root cause and don't solve the use-after-free. Add the task_work_add() call stack into the KASAN auxiliary stack in order to improve KASAN reports. It helps programmers solve use-after-free issues. [1]: https://groups.google.com/g/syzkaller-bugs/search?q=kasan%20use-after-free%20task_work_run Link: https://lkml.kernel.org/r/20210316024410.19967-1-walter-zh.wu@mediatek.com Signed-off-by: Walter Wu Suggested-by: Dmitry Vyukov Reviewed-by: Dmitry Vyukov Reviewed-by: Jens Axboe Acked-by: Oleg Nesterov Acked-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Andrew Morton Cc: Matthias Brugger Signed-off-by: Andrew Morton --- kernel/task_work.c | 3 +++ mm/kasan/kasan.h | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) --- a/kernel/task_work.c~task_work-kasan-record-task_work_add-call-stack +++ a/kernel/task_work.c @@ -34,6 +34,9 @@ int task_work_add(struct task_struct *ta { struct callback_head *head; + /* record the work call stack in order to print it in KASAN reports */ + kasan_record_aux_stack(work); + do { head = READ_ONCE(task->task_works); if (unlikely(head == &work_exited)) --- a/mm/kasan/kasan.h~task_work-kasan-record-task_work_add-call-stack +++ a/mm/kasan/kasan.h @@ -163,7 +163,7 @@ struct kasan_alloc_meta { struct kasan_track alloc_track; #ifdef CONFIG_KASAN_GENERIC /* - * call_rcu() call stack is stored into struct kasan_alloc_meta. + * The auxiliary stack is stored into struct kasan_alloc_meta. * The free stack is stored into struct kasan_free_meta. */ depot_stack_handle_t aux_stack[2];