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: <fc22e139-4eb1-45e0-5314-38f74ce4a643@gmail.com>
Date:   Sun, 30 Oct 2022 20:55:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
From:   Eli Billauer <eli.billauer@gmail.com>
Subject: Re: [PATCH v2] char: xillybus: Prevent use-after-free due to race
 condition
To:     Alan Stern <stern@rowland.harvard.edu>
Cc:     gregkh@linuxfoundation.org, arnd@arndb.de,
        linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
        imv4bel@gmail.com
References: <20221030094209.65916-1-eli.billauer@gmail.com>
 <Y16k90Lk2fehKqRC@rowland.harvard.edu>
Content-Language: en-US
In-Reply-To: <Y16k90Lk2fehKqRC@rowland.harvard.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 30/10/2022 18:23, Alan Stern wrote:
> It looks like the xillybus driver already has a private mutex that would
> have been very well suited for this task: unit_mutex defined in
> xillybus_class.c.

Indeed so. The problem is that unit_mutex is global to xillybus_class.c, 
and I need the mutex to be released in xillyusb.c: The kref counter, 
which needs to be incremented with a mutex held, is inside a structure 
that only the XillyUSB driver knows about, so xillybus_class can't do 
that. Which is why xillybus_find_inode() passed a pointer to unit_mutex 
  to its caller in the v1 version of this patch. But that turned out to 
be too odd.

> Of course, there's nothing wrong with using a new
> mutex instead -- just make sure there aren't any ABBA locking order
> problems.

The kref_mutex is always taken with no other (Xillybus-related) mutex 
taken. So the locking order is assured.

But thanks for the reminder. Never hurts checking again.

Regards,
    Eli