From: Pavel Skripkin <paskripkin@gmail.com>
To: Atul Gopinathan <atulgopinathan@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: brookebasile@gmail.com, ath9k-devel@qca.qualcomm.com,
davem@davemloft.net, kuba@kernel.org, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
Subject: Re: Memory leak in ath9k_hif_usb_dealloc_tx_urbs()
Date: Tue, 27 Apr 2021 15:29:28 +0300 [thread overview]
Message-ID: <20210427152928.0871e17a@gmail.com> (raw)
In-Reply-To: <ec48c7d118a3093289907dc43f8dfb79d4879f7d.camel@gmail.com>
On Tue, 27 Apr 2021 15:04:29 +0300
Pavel Skripkin <paskripkin@gmail.com> wrote:
> Hi!
>
> On Tue, 2021-04-27 at 17:05 +0530, Atul Gopinathan wrote:
> > On Wed, Mar 31, 2021 at 08:28:15AM +0200, Greg KH wrote:
> > > On Tue, Mar 30, 2021 at 10:36:52PM +0300, Pavel Skripkin wrote:
> > > > Hi!
> > > >
> > > > I did some debugging on this
> > > > https://syzkaller.appspot.com/bug?id=3ea507fb3c47426497b52bd82b8ef0dd5b6cc7ee
> > > > and, I believe, I recognized the problem. The problem appears in
> > > > case of
> > > > ath9k_htc_hw_init() fail. In case of this fail all tx_buf->urb
> > > > krefs will be
> > > > initialized to 1, but in free function:
> > > >
> > > > static void ath9k_hif_usb_dealloc_tx_urbs(struct hif_device_usb
> > > > *hif_dev)
> > > >
> > > > ....
> > > >
> > > > static void ath9k_hif_usb_dealloc_tx_urbs(struct hif_device_usb
> > > > *hif_dev)
> > > > {
> > > > ...
> > > > list_for_each_entry_safe(tx_buf, tx_buf_tmp,
> > > > &hif_dev->tx.tx_buf, list) {
> > > > usb_get_urb(tx_buf->urb);
> > > > ...
> > > > usb_free_urb(tx_buf->urb);
> > > > ...
> > > > }
> > > >
> > > > Krefs are incremented and then decremented, that means urbs
> > > > won't be freed.
> > > > I found your patch and I can't properly understand why You added
> > > > usb_get_urb(tx_buf->urb).
> > > > Can You explain please, I believe this will help me or somebody
> > > > to fix this ussue :)
> > >
> > > I think almost everyone who has looked into this has given up due
> > > to the
> > > mess of twisty-passages here with almost no real-world benefits
> > > for unwinding them :)
> >
> > Just wanted to confirm, what is the status of this bug then, as in
> > is it
> > invalid (not sure if that's the correct word)? I happened to stumble
> > across the same syzkaller bug report Pavel posted above, in the
> > morning.
> > Saw that there has been no patch tests/fixes on this yet according
> > to syzkaller. Spent a couple of hours going through it before
> > sending a test patch to syzbot which returned an "OK" (and the
> > patch is exactly what Pavel pointed out, I simply removed the
> > `usb_get_urb()`). Before sending anything to the mailing list, I
> > made sure to search all the relavant networking lists to see if
> > this topic had been brought up (learnt
> > to do this from my preious mistakes of sending already accepted
> > patches) and
> > luckily I found this.
> >
> > Syzbot has had 380 crashes caused by this bug, with the latest being
> > today. So I wanted to confirm what should be done be about this
> > bug.
> >
>
> I saw on dashboard, that Dmitry tested latest upstream commit and
> syzbot returned "OK", but usb_get_urb(tx_buf->urb); is still there.
>
I am sorry, I clicked wrong link on dashboard :( My bad.
I believe, You can test your patch on this
https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf.
usb_get_urb(tx_buf->urb) was introduced in patch related to this bug
> I think, this usb_get_urb prevents race condition, but I'm not sure
> about it, that's why I sent an email to patch author. As You can see,
> he has not responded yet :)
>
> > Thank you!
> > Atul
>
> With regards,
> Pavel Skripkin
>
>
With regards,
Pavel Skripkin
next prev parent reply other threads:[~2021-04-27 12:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 7:14 [PATCH] wireless: ath9k: hif_usb: fix race condition between usb_get_urb() and usb_kill_anchored_urbs() Brooke Basile
2020-09-20 2:03 ` Brooke Basile
2020-09-21 13:05 ` Kalle Valo
[not found] ` <20200921130559.005D8C43382@smtp.codeaurora.org>
2020-09-21 23:04 ` Brooke Basile
2021-03-30 19:36 ` Memory leak in ath9k_hif_usb_dealloc_tx_urbs() Pavel Skripkin
2021-03-31 6:28 ` Greg KH
2021-04-27 11:35 ` Atul Gopinathan
2021-04-27 11:50 ` Greg KH
2021-04-27 12:04 ` Pavel Skripkin
2021-04-27 12:29 ` Pavel Skripkin [this message]
2021-04-27 13:01 ` Atul Gopinathan
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=20210427152928.0871e17a@gmail.com \
--to=paskripkin@gmail.com \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=atulgopinathan@gmail.com \
--cc=brookebasile@gmail.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=syzbot+89bd486af9427a9fc605@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.