mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Eli Billauer <eli.billauer@gmail.com>
Cc: gregkh@linuxfoundation.org, arnd@arndb.de,
	linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	imv4bel@gmail.com
Subject: Re: [PATCH] char: xillybus: Prevent use-after-free due to race condition
Date: Wed, 26 Oct 2022 11:02:17 -0400	[thread overview]
Message-ID: <Y1lL+dVsJo2zu3Gy@rowland.harvard.edu> (raw)
In-Reply-To: <2e5cbdfe-f6cd-d24f-9785-55176af6c975@gmail.com>

On Wed, Oct 26, 2022 at 11:52:40AM +0300, Eli Billauer wrote:
> xillybus_find_inode() is called by xillybus_open() and xillyusb_open()
> to translate the inode's major and minor into a pointer to a relevant
> data structure and an index.
> 
> But with xillyusb_open(), the data structure can be freed by
> xillyusb_disconnect() during an unintentional time gap between the
> release of the mutex that is taken by xillybus_find_inode() and the
> mutex that is subsequently taken by xillyusb_open().
> 
> To fix this, xillybus_find_inode() supplies the pointer to the mutex that
> it has locked (when returning success), so xillyusb_open() releases this
> mutex only after obtaining the mutex that is specific to a device file.
> This ensures that xillyusb_disconnect() won't release anything that is in
> use.

The standard way of handling this problem is different from this.  The 
driver defines a private mutex, and it ensures that any routine calling 
*_find_inode() holds the mutex.  It also ensures that the mutex is held 
while a new device is being registered and while a device is being 
removed.

Even that won't fix all the synchronization problems.  A process can 
open a device, and then after the device has been removed the process 
can still try to access the device.  The driver needs to ensure that 
such accesses are not allowed.

Alan Stern

  parent reply	other threads:[~2022-10-26 15:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26  8:52 Eli Billauer
2022-10-26 12:07 ` Greg KH
2022-10-27  8:01   ` Eli Billauer
2022-10-26 15:02 ` Alan Stern [this message]
2022-10-27  8:05   ` 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=Y1lL+dVsJo2zu3Gy@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=arnd@arndb.de \
    --cc=eli.billauer@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=imv4bel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®