All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eli Billauer <eli.billauer@gmail.com>
To: Hyunwoo Kim <imv4bel@gmail.com>
Cc: gregkh@linuxfoundation.org, arnd@arndb.de,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	stern@rowland.harvard.edu
Subject: Re: [PATCH v2] char: xillybus: Prevent use-after-free due to race condition
Date: Sun, 13 Nov 2022 10:30:16 +0200	[thread overview]
Message-ID: <2a8f59ac-9d49-ffa3-b035-809f2fac38ec@gmail.com> (raw)
In-Reply-To: <20221113080558.GA5854@ubuntu>

On 13/11/2022 10:05, Hyunwoo Kim wrote:
> Dear,
> 
> Sorry for the late review.
> 
> This patch cannot prevent the UAF scenario I presented:
> ```
>                  cpu0                                                cpu1
>         1. xillyusb_open()
>            mutex_lock(&kref_mutex);    // unaffected lock
>            xillybus_find_inode()
>            mutex_lock(&unit_mutex);
>            unit = iter;
>            mutex_unlock(&unit_mutex);
>                                                               2. xillyusb_disconnect()
>                                                                  xillybus_cleanup_chrdev()
>                                                                  mutex_lock(&unit_mutex);
>                                                                  kfree(unit);
>                                                                  mutex_unlock(&unit_mutex);
>         3. *private_data = unit->private_data;   // UAF
> 
> ```
> 
> This is a UAF for 'unit', not a UAF for 'xdev'.
> So, the added 'kref_mutex' has no effect.
> 

You're correct. This submitted patch solves only one problem out of two. 
It prevents the content of @private_data to be freed, but you're right 
that @unit itself isn't protected well enough.

The problem you're pointing at is that @unit can be freed before its 
attempted use, because the mutex is released too early.

This is easily solved by moving down the mutex_unlock() call to after 
@unit has been used. Do you want the pleasure to submit this patch, or 
should I?

Thanks,
   Eli

  reply	other threads:[~2022-11-13  8:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-30  9:42 [PATCH v2] char: xillybus: Prevent use-after-free due to race condition Eli Billauer
2022-10-30 16:23 ` Alan Stern
2022-10-30 18:55   ` Eli Billauer
2022-11-13  8:05 ` Hyunwoo Kim
2022-11-13  8:30   ` Eli Billauer [this message]
2022-11-13  8:47     ` Hyunwoo Kim
2022-11-13  9:03       ` Eli Billauer
2022-11-13  9:14         ` Hyunwoo Kim
2022-11-13 11:36           ` Eli Billauer

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=2a8f59ac-9d49-ffa3-b035-809f2fac38ec@gmail.com \
    --to=eli.billauer@gmail.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=imv4bel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.