The patch titled
Subject: workqueue: kasan: record workqueue stack
has been added to the -mm tree. Its filename is
workqueue-kasan-record-workqueue-stack.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/workqueue-kasan-record-workqueue-stack.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/workqueue-kasan-record-workqueue-stack.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Walter Wu <walter-zh.wu@xxxxxxxxxxxx>
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@xxxxxxxxxxxx
Link: https://lkml.kernel.org/r/20201203022442.30006-1-walter-zh.wu@xxxxxxxxxxxx
Signed-off-by: Walter Wu <walter-zh.wu@xxxxxxxxxxxx>
Suggested-by: Marco Elver <elver@xxxxxxxxxx>
Acked-by: Marco Elver <elver@xxxxxxxxxx>
Acked-by: Tejun Heo <tj@xxxxxxxxxx>
Reviewed-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
Reviewed-by: Andrey Konovalov <andreyknvl@xxxxxxxxxx>
Cc: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
Cc: Alexander Potapenko <glider@xxxxxxxxxx>
Cc: Lai Jiangshan <jiangshanlai@xxxxxxxxx>
Cc: Marco Elver <elver@xxxxxxxxxx>
Cc: Matthias Brugger <matthias.bgg@xxxxxxxxx>
Cc: Jonathan Corbet <corbet@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
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);
_
Patches currently in -mm which might be from walter-zh.wu@xxxxxxxxxxxx are
workqueue-kasan-record-workqueue-stack.patch
kasan-print-workqueue-stack.patch
lib-test_kasanc-add-workqueue-test-case.patch
kasan-update-documentation-for-generic-kasan.patch
