From: Shuah Khan <skhan@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Valentina Manea <valentina.manea.m@gmail.com>,
Shuah Khan <shuah@kernel.org>
Cc: Hillf Danton <hdanton@sina.com>,
linux-usb@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usb: usbip: fix error handling of kthread_get_run()
Date: Wed, 10 Feb 2021 13:15:11 -0700 [thread overview]
Message-ID: <f97b85c7-d319-0897-e0f1-29c4154ca060@linuxfoundation.org> (raw)
In-Reply-To: <bb8f438f-8a77-2aac-cb2b-b2551f6a64b0@i-love.sakura.ne.jp>
On 2/10/21 11:43 AM, Tetsuo Handa wrote:
> On 2021/02/11 3:20, Shuah Khan wrote:
>> On 2/10/21 11:16 AM, Tetsuo Handa wrote:
>>> On 2021/02/11 3:11, Shuah Khan wrote:
>>>> I would like to see to see a complete fix. This patch changes
>>>> kthread_get_run() to return NULL. Without adding handling for
>>>> NULL in the callers of kthread_get_run(), we will start seeing
>>>> problems.
>>>
>>> What problems are you aware of?
>>>
>>
>> The fact that driver doesn't cleanup after failing to create
>> the thread is a problem.
>
> What are the cleanup functions?
>
When user-space requests attaching to a device, attach_store()
tries to attach the requested device. When kthread_get_run()
failure is ignored silently, and continue with call to
rh_port_connect(), user-space assumes attach is successful.
User thinks attach is successful.
When and how will this attach failure gets reported to the
in this scenario?
Error handling for this case is no different from other error
paths in attach_store().
Please see error handling for other errors in attach_store().
In this case the right error handling is to rewind the vdev
init and bail out returning error. This would include setting
vdev->ud.status to VDEV_ST_NULL.
I found the following reproducer that tells me how attach
is triggered.
https://syzkaller.appspot.com/text?tag=ReproC&x=128506e4d00000
syzbot is helping us harden these paths, which is awesome.
Fixing these have to consider user api.
I you would like to fix this, please send me a complete fix.
thanks,
-- Shuah
next prev parent reply other threads:[~2021-02-10 20:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-20 18:44 KASAN: null-ptr-deref Write in vhci_shutdown_connection syzbot
2021-02-05 13:57 ` [PATCH] usb: usbip: fix error handling of kthread_get_run() Tetsuo Handa
2021-02-05 16:27 ` Shuah Khan
2021-02-06 1:08 ` Tetsuo Handa
2021-02-10 18:11 ` Shuah Khan
2021-02-10 18:16 ` Tetsuo Handa
2021-02-10 18:20 ` Shuah Khan
2021-02-10 18:43 ` Tetsuo Handa
2021-02-10 20:15 ` Shuah Khan [this message]
2021-02-11 1:04 ` Tetsuo Handa
2021-02-11 3:01 ` Tetsuo Handa
2021-02-11 13:40 ` Tetsuo Handa
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=f97b85c7-d319-0897-e0f1-29c4154ca060@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=hdanton@sina.com \
--cc=linux-usb@vger.kernel.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=shuah@kernel.org \
--cc=valentina.manea.m@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).