From: Shuah Khan <skhan@linuxfoundation.org>
To: Andrey Konovalov <andreyknvl@google.com>
Cc: Shuah Khan <shuah@kernel.org>,
Valentina Manea <valentina.manea.m@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
USB list <linux-usb@vger.kernel.org>,
syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
syzbot <syzbot+bf1a360e305ee719e364@syzkaller.appspotmail.com>,
Nazime Hande Harputluoglu <handeharputlu@google.com>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: KASAN: null-ptr-deref Write in event_handler
Date: Fri, 16 Oct 2020 13:48:00 -0600 [thread overview]
Message-ID: <9256b41b-fe27-a453-ab30-8999379bc1e3@linuxfoundation.org> (raw)
In-Reply-To: <5e0e21bd-5cc9-f1d8-d45e-ec7f10edbfba@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]
On 10/7/20 9:48 AM, Shuah Khan wrote:
> On 10/7/20 8:28 AM, Andrey Konovalov wrote:
>> On Wed, Oct 7, 2020 at 3:56 PM Shuah Khan <skhan@linuxfoundation.org>
>> wrote:
>>>
[snip]
>>>
>>> Hi Andrey,
>>>
>>> I have been unable to reproduce the problem with the reproducer
>>> so far. You mentioned it happens quite often.
>>>
>>> - matched config with yours
>>> - load vhci_hcd module and run the reproducer
>>
>> Hm, if you matched the config, then the module should be built-in?
>>
>
> Right. I did notice that your config has built-in. This shouldn't
> matter, I have a kernel built with it static. I will try it to
> see if it makes a difference.
>
>>>
>>> I do see the messages during shutdown - stop threads etc.
>>>
>>> What am I missing?
>>
>> This appears to be a race that requires precise timings. I failed to
>> reproduce it with the C reproducer, but I managed to reproduce it with
>> the syzkaller repro program:
>>
>> https://syzkaller.appspot.com/x/repro.syz?x=16cbaa7d900000
>>
>> To do that you need to build syzkaller, and copy ./bin/syz-execprog
>> and ./bin/syz-executor into your testing environment, and then do:
>>
>> ./syz-execprog -sandbox=none -repeat=0 -procs=6 ./repro.prog
>>
>
Andrey,
I am unable to reproduce the problem. I even tweaked the reproducer
to launch 10 procs and 100 threads.
Can you test the following patch with your setup
Here it is - also attached.
=======================================================================
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 66cde5e5f796..3fdcb93b667d 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -997,14 +997,12 @@ static void vhci_device_unlink_cleanup(struct
vhci_device *vdev)
spin_unlock_irqrestore(&vhci->lock, flags);
}
-/*
- * The important thing is that only one context begins cleanup.
- * This is why error handling and cleanup become simple.
- * We do not want to consider race condition as possible.
- */
static void vhci_shutdown_connection(struct usbip_device *ud)
{
struct vhci_device *vdev = container_of(ud, struct vhci_device, ud);
+ struct vhci_hcd *vhci_hcd = vdev_to_vhci_hcd(vdev);
+ struct vhci *vhci = vhci_hcd->vhci;
+ unsigned long flags;
/* need this? see stub_dev.c */
if (ud->tcp_socket) {
@@ -1012,6 +1010,10 @@ static void vhci_shutdown_connection(struct
usbip_device *ud)
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
+ /* avoid races during shutdown */
+ spin_lock_irqsave(&vhci->lock, flags);
+ spin_lock(&vdev->priv_lock);
+
/* kill threads related to this sdev */
if (vdev->ud.tcp_rx) {
kthread_stop_put(vdev->ud.tcp_rx);
@@ -1031,6 +1033,10 @@ static void vhci_shutdown_connection(struct
usbip_device *ud)
}
pr_info("release socket\n");
+ /* unlock - vhci_device_unlink_cleanup() holds the locks */
+ spin_unlock(&vdev->priv_lock);
+ spin_unlock_irqrestore(&vhci->lock, flags);
+
vhci_device_unlink_cleanup(vdev);
/*
=======================================================================
thanks,
-- Shuah
[-- Attachment #2: vhci_hcd_shutdown.diff --]
[-- Type: text/x-patch, Size: 1490 bytes --]
diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c
index 66cde5e5f796..3fdcb93b667d 100644
--- a/drivers/usb/usbip/vhci_hcd.c
+++ b/drivers/usb/usbip/vhci_hcd.c
@@ -997,14 +997,12 @@ static void vhci_device_unlink_cleanup(struct vhci_device *vdev)
spin_unlock_irqrestore(&vhci->lock, flags);
}
-/*
- * The important thing is that only one context begins cleanup.
- * This is why error handling and cleanup become simple.
- * We do not want to consider race condition as possible.
- */
static void vhci_shutdown_connection(struct usbip_device *ud)
{
struct vhci_device *vdev = container_of(ud, struct vhci_device, ud);
+ struct vhci_hcd *vhci_hcd = vdev_to_vhci_hcd(vdev);
+ struct vhci *vhci = vhci_hcd->vhci;
+ unsigned long flags;
/* need this? see stub_dev.c */
if (ud->tcp_socket) {
@@ -1012,6 +1010,10 @@ static void vhci_shutdown_connection(struct usbip_device *ud)
kernel_sock_shutdown(ud->tcp_socket, SHUT_RDWR);
}
+ /* avoid races during shutdown */
+ spin_lock_irqsave(&vhci->lock, flags);
+ spin_lock(&vdev->priv_lock);
+
/* kill threads related to this sdev */
if (vdev->ud.tcp_rx) {
kthread_stop_put(vdev->ud.tcp_rx);
@@ -1031,6 +1033,10 @@ static void vhci_shutdown_connection(struct usbip_device *ud)
}
pr_info("release socket\n");
+ /* unlock - vhci_device_unlink_cleanup() holds the locks */
+ spin_unlock(&vdev->priv_lock);
+ spin_unlock_irqrestore(&vhci->lock, flags);
+
vhci_device_unlink_cleanup(vdev);
/*
next prev parent reply other threads:[~2020-10-16 19:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 13:59 KASAN: null-ptr-deref Write in event_handler syzbot
2020-10-05 14:04 ` Andrey Konovalov
2020-10-05 20:44 ` Shuah Khan
2020-10-07 13:56 ` Shuah Khan
2020-10-07 14:28 ` Andrey Konovalov
2020-10-07 15:48 ` Shuah Khan
2020-10-16 19:48 ` Shuah Khan [this message]
2020-10-19 15:10 ` Andrey Konovalov
2020-10-19 15:22 ` Shuah Khan
[not found] ` <20201007103029.16388-1-hdanton@sina.com>
2020-10-09 14:37 ` Shuah Khan
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=9256b41b-fe27-a453-ab30-8999379bc1e3@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=andreyknvl@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=handeharputlu@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=syzbot+bf1a360e305ee719e364@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--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).