linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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);
 
 	/*

  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).