Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2a8f59ac-9d49-ffa3-b035-809f2fac38ec@gmail.com>
Date:   Sun, 13 Nov 2022 10:30:16 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH v2] char: xillybus: Prevent use-after-free due to race
 condition
Content-Language: en-US
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
References: <20221030094209.65916-1-eli.billauer@gmail.com>
 <20221113080558.GA5854@ubuntu>
From:   Eli Billauer <eli.billauer@gmail.com>
In-Reply-To: <20221113080558.GA5854@ubuntu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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