[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1911201109500.1498-100000@iolanthe.rowland.org>
Date: Wed, 20 Nov 2019 11:14:05 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: Pete Zaitcev <zaitcev@...hat.com>,
syzbot <syzbot+56f9673bb4cdcbeb0e92@...kaller.appspotmail.com>
cc: arnd@...db.de, <gregkh@...uxfoundation.org>,
<jrdr.linux@...il.com>, <keescook@...omium.org>,
<kstewart@...uxfoundation.org>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB list <linux-usb@...r.kernel.org>,
<syzkaller-bugs@...glegroups.com>, <tglx@...utronix.de>,
<viro@...iv.linux.org.uk>
Subject: Re: possible deadlock in mon_bin_vma_fault
On Wed, 20 Nov 2019, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 46eb14a6e1585d99c1b9f58d0e7389082a5f466b
> Author: Pete Zaitcev <zaitcev@...hat.com>
> Date: Mon Jan 8 21:46:41 2018 +0000
>
> USB: fix usbmon BUG trigger
Here's part of the commit description:
USB: fix usbmon BUG trigger
Automated tests triggered this by opening usbmon and accessing the
mmap while simultaneously resizing the buffers. This bug was with
us since 2006, because typically applications only size the buffers
once and thus avoid racing. Reported by Kirill A. Shutemov.
As it happens, I spent a little time investigating this bug report just
yesterday. It seems to me that the easiest fix would be to disallow
resizing the buffer while it is mapped by any users. (Besides,
allowing that seems like a bad idea in any case.)
Pete, does that seem reasonable to you?
Alan Stern
Powered by blists - more mailing lists