[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADG63jDcuBNOVRoRX7oi1YmwuN0g7jpvDB4yNdOxwc13hvoNxA@mail.gmail.com>
Date: Tue, 17 Mar 2020 00:25:16 +0800
From: Qiujun Huang <anenbupt@...il.com>
To: Will Deacon <will@...nel.org>
Cc: Kees Cook <keescook@...omium.org>,
syzbot <syzbot+cea71eec5d6de256d54d@...kaller.appspotmail.com>,
ardb@...nel.org, davem@...emloft.net, guohanjun@...wei.com,
kuba@...nel.org, linux-kernel@...r.kernel.org,
linux-sctp@...r.kernel.org, marcelo.leitner@...il.com,
mingo@...nel.org, netdev@...r.kernel.org, nhorman@...driver.com,
syzkaller-bugs@...glegroups.com, vyasevich@...il.com
Subject: Re: WARNING: refcount bug in sctp_wfree
On Mon, Mar 16, 2020 at 11:52 PM Will Deacon <will@...nel.org> wrote:
>
> On Tue, Mar 10, 2020 at 09:01:18AM -0700, Kees Cook wrote:
> > On Tue, Mar 10, 2020 at 02:39:01AM -0700, syzbot wrote:
> > > syzbot has bisected this bug to:
> > >
> > > commit fb041bb7c0a918b95c6889fc965cdc4a75b4c0ca
> > > Author: Will Deacon <will@...nel.org>
> > > Date: Thu Nov 21 11:59:00 2019 +0000
> > >
> > > locking/refcount: Consolidate implementations of refcount_t
> >
> > I suspect this is just bisecting to here because it made the refcount
> > checks more strict?
>
> Yes, this is the commit that enables full refcount checking for all
> architectures unconditionally, so it's the canary in the coalmine rather
> than the source of the problem.
Yes, I tracked it down. And sent out a fix:
https://lore.kernel.org/netdev/1584330804-18477-1-git-send-email-hqjagain@gmail.com
>
> Will
Powered by blists - more mailing lists