On Tue, 2020-12-01 at 15:02 +0100, 'Dmitry Vyukov' via kasan-dev wrote: > On Tue, Dec 1, 2020 at 12:17 PM Walter Wu <walter-zh...@mediatek.com> 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 <t...@linutronix.de> > > > 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. > Yes, call stack already is useful for it in KASAN report.
> 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). > Got it. I will remove timer patch and send v5. Thanks for your suggestion. Walter