Re: [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit.

From: Andrey Konovalov <andreyknvl@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.com>,
	Colin Ian King <colin.king@canonical.com>,
	Arnd Bergmann <arnd@arndb.de>,
	USB list <linux-usb@vger.kernel.org>,
	syzbot <syzbot+854768b99f19e89d7f81@syzkaller.appspotmail.com>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: [PATCH] USB: cdc-wdm: Call wake_up_all() when clearing WDM_IN_USE bit.
Date: Thu, 28 May 2020 21:03:43 +0200	[thread overview]
Message-ID: <CAAeHK+ww0u0G94z_Y7VXLCVTQVZ9thO0q69n+Fj3jKT6MtpPng@mail.gmail.com> (raw)
In-Reply-To: <27b7545e-8f41-10b8-7c02-e35a08eb1611@i-love.sakura.ne.jp>

On Thu, May 28, 2020 at 6:03 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2020/05/29 0:18, Andrey Konovalov wrote:
> >> I might have found what is wrong.
> >>
> >> My understanding is that a process using /dev/raw-gadget is responsible for
> >> reacting to every USB request. I don't know whether /dev/raw-gadget already
> >> provides callback for aborting the in-flight USB requests (in order to resume
> >> wdm_flush()) when /dev/raw-gadget is closed (due to explicit close() syscall or
> >> implicit exit_files() from do_exit() upon SIGKILL). I assume /dev/raw-gadget
> >> already provides such callback in the following paragraphs.
> >
> > raw-gadget should kill all unfishished USB requests when the file is closed.
>
> I see. But
>
> >
> >>
> >> Since the reproducer is opening both /dev/raw-gadget (which is char-10-62) and
> >> /dev/cdc-wdm0 (which is char-180-0), it seems that the kernel is falling into
> >> deadlock condition due to the need to close both files when the reproducer is
> >> killed. My guess is that since that process is stuck at wdm_flush() (due to
> >> explicit close() syscall or implicit exit_files() from do_exit() upon SIGKILL),
> >> that process cannot react to USB requests which are needed for resuming wdm_flush().
> >> Unexpectedly blocking a process which is responsible for reacting to USB requests
> >> will look as if it is a broken hardware.
> >
> > Hm, so wdm_flush() is unable to finish unless an expected USB request
> > is received from the device? This is a bug in the wdm driver then.
>
> this specific bug report is caused by being unable to close /dev/cdc-wdm0
> due to /dev/raw-gadget API usage bug in the userspace process. In other words,
> this bug report should be closed with "#syz invalid" like a bug report at
> https://syzkaller.appspot.com/bug?id=287aa8708bc940d0ca1645223c53dd4c2d203be6
> which unexpectedly did ioctl(FIFREEZE) without corresponding ioctl(FITHAW).
>
> > Should we use wait_event_interruptible() instead of wait_event() in
> > wdm_flush()?
>
> That only shadows this kind of bug reports, by not using TASK_UNINTERRUPTIBLE.
>
> The problem that the userspace process which is responsible for closing
> /dev/raw-gadget gets stuck at wdm_flush() unless interrupted by a signal
> when closing /dev/cdc-wdm0 is remaining. I think that a process should not
> open /dev/raw-gadget and /dev/cdc-wdm0 at the same time.

Ah, so the problem is that when a process exits, it tries to close wdm
fd first, which ends up calling wdm_flush(), which can't finish
because the USB requests are not terminated before raw-gadget fd is
closed, which is supposed to happen after wdm fd is closed. Is this
correct? I wonder what will happen if a real device stays connected
and ignores wdm requests.

I don't understand though, how using wait_event_interruptible() will
shadow anything here.

Alan, Greg, is this acceptable behavior for a USB driver?