linux-kernel - Re: [PATCH] char: xillybus: Prevent use-after-free due to race condition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Oct 2022 14:07:38 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Eli Billauer <eli.billauer@...il.com>
Cc:     arnd@...db.de, linux-kernel@...r.kernel.org,
        linux-usb@...r.kernel.org, imv4bel@...il.com
Subject: Re: [PATCH] char: xillybus: Prevent use-after-free due to race
 condition

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.

That's really odd, and not normal at all.  We don't pass around mutexes
like this as how do you know if that's allowed?

> 
> This manipulation of mutexes poses no risk for a deadlock, because in
> all usage scenarios, @unit_mutex (which is locked by xillybus_find_inode)
> is always taken when no other mutex is locked. Hence a consistent locking
> order is guaranteed.
> 
> xillybus_open() unlocks this mutex immediately, as this driver doesn't
> support hot unplugging anyhow.
> 
> Reported-by: Hyunwoo Kim <imv4bel@...il.com>
> Signed-off-by: Eli Billauer <eli.billauer@...il.com>
> ---
> drivers/char/xillybus/xillybus_class.c | 8 +++++---
> drivers/char/xillybus/xillybus_class.h | 2 ++
> drivers/char/xillybus/xillybus_core.c  | 6 +++++-
> drivers/char/xillybus/xillyusb.c       | 4 +++-
> 4 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/char/xillybus/xillybus_class.c b/drivers/char/xillybus/xillybus_class.c
> index 0f238648dcfe..c846dc3ed225 100644
> --- a/drivers/char/xillybus/xillybus_class.c
> +++ b/drivers/char/xillybus/xillybus_class.c
> @@ -211,6 +211,7 @@ void xillybus_cleanup_chrdev(void *private_data,
> EXPORT_SYMBOL(xillybus_cleanup_chrdev);
> 
> int xillybus_find_inode(struct inode *inode,
> +			struct mutex **to_unlock,

To unlock when?  Who unlocks it?  What is the lifespan here?

Why can't it just be part of the structure?

> 			void **private_data, int *index)
> {
> 	int minor = iminor(inode);
> @@ -227,13 +228,14 @@ int xillybus_find_inode(struct inode *inode,
> 			break;
> 		}
> 
> -	mutex_unlock(&unit_mutex);
> -
> -	if (!unit)
> +	if (!unit) {
> +		mutex_unlock(&unit_mutex);
> 		return -ENODEV;
> +	}
> 
> 	*private_data = unit->private_data;
> 	*index = minor - unit->lowest_minor;
> +	*to_unlock = &unit_mutex;

Why are you wanting the caller to unlock this?  It's a global mutex (for
the whole file), this feels really odd.

What is this function supposed to be doing?  You only return an int, and
you have some odd opaque void pointer being set.  That feels wrong and
is not a normal design at all.

confused,

greg k-h