From: Tetsuo Handa <email@example.com>
To: Shuah Khan <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Valentina Manea <firstname.lastname@example.org>,
Shuah Khan <email@example.com>
Cc: Hillf Danton <firstname.lastname@example.org>,
email@example.com, Arnd Bergmann <firstname.lastname@example.org>
Subject: Re: [PATCH] usb: usbip: fix error handling of kthread_get_run()
Date: Thu, 11 Feb 2021 10:04:07 +0900 [thread overview]
Message-ID: <email@example.com> (raw)
On 2021/02/11 5:15, Shuah Khan wrote:
> 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
>>>> 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.
struct kthread_create_info *create = kmalloc(sizeof(*create), GFP_KERNEL);
in __kthread_create_on_node() never fails unless killed by the OOM killer
due to the "too small to fail" memory-allocation rule, and
in __kthread_create_on_node() never fails unless killed. Creating a kernel
thread as root user unlikely fails, and memory allocations by that kernel
thread also never fails due to the "too small to fail" memory-allocation rule.
Therefore, kthread_get_run() effectively fails only when current thread
which called attach_store() was killed. And
> When and how will this attach failure gets reported to the
> in this scenario?
if the current thread was killed, how can the failure get reported to
the user-space 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().
Being "killed" means that user-space can never know the result
unlike other error paths 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.
If the user-space was killed, the kernel is responsible for offering
automatic cleanup which includes setting vdev->ud.status to VDEV_ST_NULL.
> I found the following reproducer that tells me how attach
> is triggered.
This reproducer (which is killed after 5 seconds from fork()) uses
only /sys/devices/platform/vhci_hcd.0/attach interface and never uses
detach interface. Detach and cleanup are up to automatic cleanup
offered by the kernel.
> 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.
If you want to handle the unlikely "__kthread_create_on_node() fails without
being killed" case, such change ( the drivers/usb/usbip/vhci_sysfs.c portion in
https://syzkaller.appspot.com/x/patch.diff?x=16c3c090d00000 ) should be a separate
patch. Since this patch declares "Fixes: 9720b4bc76a83807 ("staging/usbip: convert to kthread")",
this patch intends for the minimal change and does not want to do extra things.
next prev parent reply other threads:[~2021-02-11 1:05 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
2021-02-11 1:04 ` Tetsuo Handa [this message]
2021-02-11 3:01 ` Tetsuo Handa
2021-02-11 13:40 ` Tetsuo Handa
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).