All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Shuah Khan <skhan@linuxfoundation.org>,
	shuah@kernel.org, valentina.manea.m@gmail.com,
	gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] usbip: fix stub_dev usbip_sockfd_store() races leading to gpf
Date: Mon, 8 Mar 2021 19:10:42 +0900	[thread overview]
Message-ID: <5df3d221-9e78-4cbe-826b-81cbfc4d5888@i-love.sakura.ne.jp> (raw)
In-Reply-To: <05aed75a-4a81-ef59-fc4f-6007f18e7839@i-love.sakura.ne.jp>

On 2021/03/08 16:35, Tetsuo Handa wrote:
> On 2021/03/08 12:53, Shuah Khan wrote:
>> Fix the above problems:
>> - Stop using kthread_get_run() macro to create/start threads.
>> - Create threads and get task struct reference.
>> - Add kthread_create() failure handling and bail out.
>> - Hold usbip_device lock to update local and shared states after
>>   creating rx and tx threads.
>> - Update usbip_device status to SDEV_ST_USED.
>> - Update usbip_device tcp_socket, sockfd, tcp_rx, and tcp_tx
>> - Start threads after usbip_device (tcp_socket, sockfd, tcp_rx, tcp_tx,
>>   and status) is complete.
> 
> No, the whole usbip_sockfd_store() etc. should be serialized using a mutex,
> for two different threads can open same file and write the same content at
> the same moment. This results in seeing SDEV_ST_AVAILABLE and creating two
> threads and overwiting global variables and setting SDEV_ST_USED and starting
> two threads by each of two thread, which will later fail to call kthread_stop()
> on one of two thread because global variables are overwritten.
> 
> kthread_crate() (which involves GFP_KERNEL allocation) can take long time
> enough to hit
> 
>   usbip_sockfd_store() must perform
> 
>       if (sdev->ud.status != SDEV_ST_AVAILABLE) {

Oops. This is

	if (sdev->ud.status == SDEV_ST_AVAILABLE) {

of course.

>         /* misc assignments for attach operation */
>         sdev->ud.status = SDEV_ST_USED;
>       }
> 
>   under a lock, or multiple ud->tcp_{tx,rx} are created (which will later
>   cause a crash like [1]) and refcount on ud->tcp_socket is leaked when
>   usbip_sockfd_store() is concurrently called.
> 
> problem. That's why my patch introduced usbip_event_mutex lock.
> 

And I think that same serialization is required between "rh_port_connect() from attach_store()" and
"rh_port_disconnect() from vhci_shutdown_connection() via usbip_event_add(&vdev->ud, VDEV_EVENT_DOWN)
 from vhci_port_disconnect() from detach_store()", for both vhci_rx_pdu() from vhci_rx_loop() and
vhci_port_disconnect() from detach_store() can queue VDEV_EVENT_DOWN event which can be processed
without waiting for attach_store() to complete.

  reply	other threads:[~2021-03-08 10:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08  3:53 [PATCH 0/6] usbip fixes to crashes found by syzbot Shuah Khan
2021-03-08  3:53 ` [PATCH 1/6] usbip: fix stub_dev to check for stream socket Shuah Khan
2021-03-08  3:53 ` [PATCH 2/6] usbip: fix vhci_hcd " Shuah Khan
2021-03-08  3:53 ` [PATCH 3/6] usbip: fix vudc " Shuah Khan
2021-03-08  3:53 ` [PATCH 4/6] usbip: fix stub_dev usbip_sockfd_store() races leading to gpf Shuah Khan
2021-03-08  7:35   ` Tetsuo Handa
2021-03-08 10:10     ` Tetsuo Handa [this message]
2021-03-08 16:27       ` Shuah Khan
2021-03-09 11:04         ` Tetsuo Handa
2021-03-09 13:56           ` Tetsuo Handa
2021-03-09 19:50           ` Shuah Khan
2021-03-09 23:40             ` Tetsuo Handa
2021-03-09 23:52               ` Shuah Khan
2021-03-10  0:03                 ` Tetsuo Handa
2021-03-10  0:29                   ` Shuah Khan
2021-03-10  1:02                     ` Tetsuo Handa
2021-03-10  2:07                       ` Shuah Khan
2021-03-10 10:38                         ` Tetsuo Handa
2021-03-09 15:22         ` Shuah Khan
2021-03-08  3:53 ` [PATCH 5/6] usbip: fix vhci_hcd attach_store() " Shuah Khan
2021-03-08  3:53 ` [PATCH 6/6] usbip: fix vudc usbip_sockfd_store " Shuah Khan
2021-03-10 18:33 ` [PATCH 0/6] usbip fixes to crashes found by syzbot Greg KH
2021-03-11 12:34   ` Tetsuo Handa
2021-03-11 12:57     ` Greg KH
2021-03-11 13:24       ` Tetsuo Handa
2021-03-12  5:44         ` Tetsuo Handa
2021-03-13  0:48           ` Tetsuo Handa
2021-03-14 11:38             ` Tetsuo Handa
2021-03-17  6:21               ` Tetsuo Handa
2021-03-17 15:06                 ` Shuah Khan
2021-03-17 15:38                   ` Tetsuo Handa
2021-03-17 17:09                     ` Shuah Khan
2021-03-18 13:13                   ` Shuah Khan
2021-03-18 13:39                     ` 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=5df3d221-9e78-4cbe-826b-81cbfc4d5888@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.