From: Lai Jiangshan <jiangshanlai@gmail.com>
To: Pavel Skripkin <paskripkin@gmail.com>
Cc: Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Yang Yingliang <yangyingliang@huawei.com>,
Xu Qiang <xuqiang36@huawei.com>
Subject: Re: BUG in alloc_workqueue (linux-next)
Date: Fri, 9 Jul 2021 11:59:01 +0800 [thread overview]
Message-ID: <CAJhGHyBrm0iowGdX8=NDr=tBG8qM8rke2ouxWVhJRTP+pxXGJw@mail.gmail.com> (raw)
In-Reply-To: <20210708162417.777bff77@gmail.com>
Hello, Pavel
Thanks for the report.
Huawei (CC-ed) is also dealing with the problem:
https://lore.kernel.org/lkml/20210708093136.2195752-1-yangyingliang@huawei.com/t/#u
Could you have a try on the fix, please?
Thanks
Lai
On Thu, Jul 8, 2021 at 9:24 PM Pavel Skripkin <paskripkin@gmail.com> wrote:
>
> I've spent some time trying to came up with a fix, but I gave
> up :( But! I have an idea about what's happening, maybe it will help
> somehow...
>
>
> So, all 3 reports have same stack trace: alloc_workqueue() in
> loop_configure(). I skimmed through syzbot's log and found, that syzbot injected
> failure into alloc_unbound_pwq() in all 3 cases:
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 1 PID: 17986 Comm: syz-executor.0 Tainted: G W 5.13.0-next-20210706 #9
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014
> Call Trace:
> dump_stack_lvl (lib/dump_stack.c:106 (discriminator 4))
> should_fail.cold (lib/fault-inject.c:52 lib/fault-inject.c:146)
> should_failslab (mm/slab_common.c:1327)
> kmem_cache_alloc_node (mm/slab.h:487 mm/slub.c:2902 mm/slub.c:3017)
> ? alloc_unbound_pwq (kernel/workqueue.c:3813)
> alloc_unbound_pwq (kernel/workqueue.c:3813)
> apply_wqattrs_prepare (kernel/workqueue.c:3963)
> apply_workqueue_attrs_locked (kernel/workqueue.c:4041)
> alloc_workqueue (kernel/workqueue.c:4078 kernel/workqueue.c:4201 kernel/workqueue.c:4309)
>
>
> So, if alloc_unbound_pwq() fails, apply_wqattrs_prepare() will jump to
> this code:
>
> out_free:
> free_workqueue_attrs(tmp_attrs);
> free_workqueue_attrs(new_attrs);
> apply_wqattrs_cleanup(ctx); <----|
> return NULL; |
> |
> put_pwq_unlocked() -> put_pwq() -> schedule_work(&pwq->unbound_release_work);
>
>
> and apply_wqattrs_cleanup() will schedule pwq_unbound_release_workfn()
> [2], but alloc_workqueue() will free workqueue_struct in case of
> alloc_unbound_pwq() error [1]. In that case we will get UAF in pwq_unbound_release_workfn()
> like in 3rd report.
>
>
> Does written above make some sence? :)
>
>
>
> With regards,
> Pavel Skripkin
next prev parent reply other threads:[~2021-07-09 3:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 13:24 BUG in alloc_workqueue (linux-next) Pavel Skripkin
2021-07-09 3:59 ` Lai Jiangshan [this message]
2021-07-09 6:57 ` Pavel Skripkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJhGHyBrm0iowGdX8=NDr=tBG8qM8rke2ouxWVhJRTP+pxXGJw@mail.gmail.com' \
--to=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paskripkin@gmail.com \
--cc=tj@kernel.org \
--cc=xuqiang36@huawei.com \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).