[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZQiRncEYCK3RYXA7@slm.duckdns.org>
Date: Mon, 18 Sep 2023 08:06:21 -1000
From: Tejun Heo <tj@...nel.org>
To: Z qiang <qiang.zhang1211@...il.com>
Cc: jiangshanlai@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: Fix UAF report by KASAN in
pwq_release_workfn()
On Thu, Sep 07, 2023 at 10:13:23AM +0800, Z qiang wrote:
> >
> > On Wed, Sep 06, 2023 at 10:12:34AM +0800, Z qiang wrote:
> > > Flush the pwq_release_worker is insufficient, the call_rcu() is
> > > invoked to release wq
> > > in pwq_release_workfn(), this is also asynchronous.
> >
> > But rcu_free_pwq() doesn't access wq or anything. The last access is from
> > the work function.
>
> The rcu_free_wq() will access wq->cpu_pwq or unbound_attrs,
> but at this time, the kfree(wq) may have been called in alloc_workqueue().
I'm not following. The only way alloc_and_link fails is if
apply_wqattrs_prepare() fails and if prepare fails, none of the pwq's are
installed and pwq_unbound_release_workfn() won't try to free the wq as the
pwq's don't have any reference on it. So, if you flush the pwq release work
items, there can be no rcu_free_wq() in flight. Can you please try to see
whether the problem is reproducible with flushing?
Thanks.
--
tejun
Powered by blists - more mailing lists