linux-kernel - Re: NULL ptr deref in wq_worker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADLLry5bKjVB5BM7HVF8wOPXkQWpQ-6xM=F78MDRHhpCxE=uBw@mail.gmail.com>
Date:   Wed, 7 Aug 2019 22:33:31 +0900
From:   Austin Kim <austindh.kim@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Sasha Levin <sashal@...nel.org>, peterz@...radead.org,
        mingo@...nel.org, tj@...nel.org, jiangshanlai@...il.com,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        #서형진 <mike.seo@....com>
Subject: Re: NULL ptr deref in wq_worker_sleeping on 4.19

Is it possible for you to generate kernel patch only with **kernel
log** for 'use-after-free' case?
With kernel log, we only have limited information, so it is hard to
debug 'use-after-free' case with this signature.

For this matter, kernel should be compiled with below config.
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB_DEBUG_ON=y

2019년 8월 7일 (수) 오후 9:56, Thomas Gleixner <tglx@...utronix.de>님이 작성:
>
> On Wed, 7 Aug 2019, Austin Kim wrote:
>
>   A: Because it messes up the order in which people normally read text.
>   Q: Why is top-posting such a bad thing?
>   A: Top-posting.
>   Q: What is the most annoying thing in e-mail?
>
>   A: No.
>   Q: Should I include quotations after my reply?
>
>   http://daringfireball.net/2007/07/on_top
>
> > I wonder what kinds of workqueue is used in case of this panic.
> >
> > If system workqueue(system_wq) is used for this case, it would be a
> > help to replace it with high priority workqueue(system_highpri_wq). If
> > panic disappers with high priority workqueue(system_highpri_wq), we
> > would think about another scenario.
>
> How would that help? As Sebastian explained, something overwrote memory or
> it is a Use After Free. How would a high priority workqueue 'fix' that?
>
> You need to find the root cause, which is either memory corruption or a use
> after free.
>
> Thanks,
>
>         tglx