Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <20230902115026.13460-1-qiang.zhang1211@gmail.com>
 <ZPd4yKqbvBNGV7cL@slm.duckdns.org> <CALm+0cVf+E_Y41AdEwLjm2gZAjzeKaZev1Tu1hUS-VpYH0eEHQ@mail.gmail.com>
 <ZPiwaaZaDPVexezn@slm.duckdns.org> <CALm+0cUytR3-0mcW3t24gcyP27UW3rpP5_+vpLVC3w70+0n6oQ@mail.gmail.com>
 <ZQiRncEYCK3RYXA7@slm.duckdns.org> <CALm+0cU9W2P46cKnijeQRQFKzpqUyZUykQ-UFt28f4b4ueyAZg@mail.gmail.com>
 <CAB8ipk8J1H_pNacd8SjrByqNg9mgR_V6nbgZ8Ug6cyagFFk=iQ@mail.gmail.com>
In-Reply-To: <CAB8ipk8J1H_pNacd8SjrByqNg9mgR_V6nbgZ8Ug6cyagFFk=iQ@mail.gmail.com>
From:   Z qiang <qiang.zhang1211@gmail.com>
Date:   Fri, 8 Dec 2023 16:18:04 +0800
Message-ID: <CALm+0cVWmQHZPFgG5hjTixG3TFS_7XsDq8YY8tCugMFSJi6Cpw@mail.gmail.com>
Subject: Re: [PATCH] workqueue: Fix UAF report by KASAN in pwq_release_workfn()
To:     Xuewen Yan <xuewen.yan94@gmail.com>
Cc:     Tejun Heo <tj@kernel.org>, jiangshanlai@gmail.com,
        linux-kernel@vger.kernel.org, guohua.yan@unisoc.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

>
> Hi qiang && Tejun
>
> On Tue, Sep 19, 2023 at 7:30=E2=80=AFPM Z qiang <qiang.zhang1211@gmail.co=
m> wrote:
> >
> > >
> > > 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_work=
queue().
> > >
> > > 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 a=
s the
> > > pwq's don't have any reference on it. So, if you flush the pwq releas=
e work
> > > items, there can be no rcu_free_wq() in flight. Can you please try to=
 see
> > > whether the problem is reproducible with flushing?
> > >
> >
> > you are right .  sorry,  I ignore if apply_wqattrs_prepare() fails,
> > none of the pwq is installed,
> > the install_unbound_pwq() is not invoked. I will resend v2 and test.
>
> I want to ask a question, why delete the v1?
> Although add the flush_work, the release work would release the lockdep k=
ey,
> and at the last of alloc_workqueue, it would also unregister_lockdep_key =
twice.
>

For unbound wq,  if apply_workqueue_attrs() return error,  the link_pwq() w=
ill
not be invoked, that means will not insert pwq->pwqs_node to wq->pwqs list,
that also means the is_last is false in pwq_release_workfn().


> And other question, why not free lockdep and just unregister_lockdep?
>
> 4136         if (is_last) {
> 4137                 wq_unregister_lockdep(wq);
> 4138                 call_rcu(&wq->rcu, rcu_free_wq);
> 4139         }

free lockdep in rcu_free_wq();

Thanks
Zqiang

>
> I would really appreciate it if you could help explain it.
>
> Thanks!
> BR
>
>
>
> >
> > Thanks
> > Zqiang
> >
> > >
> > > Thanks.
> > >
> > > --
> > > tejun