Date:   Thu, 23 Dec 2021 22:06:08 +0100 (CET)
From:   Richard Weinberger <richard@nod.at>
To:     "libaokun (A)" <libaokun1@huawei.com>
Cc:     Miquel Raynal <miquel.raynal@bootlin.com>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>, yukuai3@huawei.com,
        Hulk Robot <hulkci@huawei.com>
Message-ID: <509065063.197038.1640293568550.JavaMail.zimbra@nod.at>
In-Reply-To: <7e00eda5-3b35-6d3c-29fb-664b12cca6dd@huawei.com>
References: <20211105093022.1360601-1-libaokun1@huawei.com> <7e00eda5-3b35-6d3c-29fb-664b12cca6dd@huawei.com>
Subject: Re: [PATCH -next V3] ubi: fix race condition between
 ctrl_cdev_ioctl and ubi_cdev_ioctl
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Thread-Topic: fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl
Thread-Index: slnxfsVHQxu1KgdXyEQFACaCLfZ3WA==
Precedence: bulk

----- Ursprüngliche Mail -----
> Von: "libaokun (A)" <libaokun1@huawei.com>
> 在 2021/11/5 17:30, Baokun Li 写道:
> 
> ping

Thanks for your patience.
 
>> Hulk Robot reported a KASAN report about use-after-free:

[...]

>> The cause of this problem is that commit 714fb87e8bc0 make device
>> "available" before it becomes accessible via sysfs. Therefore, we
>> roll back the modification. We will fix the race condition between
>> ubi device creation and udev by removing ubi_get_device in
>> vol_attribute_show and dev_attribute_show.This avoids accessing
>> uninitialized ubi_devices[ubi_num].
>>
>> ubi_get_device is used to prevent devices from being deleted during
>> sysfs execution. However, now kernfs ensures that devices will not
>> be deleted before all reference counting are released.
>> The key process is shown in the following stack.

ubi_get_device() in dev_attribute_show() is used to detect whether
the ubi device got detached while the sysfs file is open.

Hmm. I thought for sysfs this is not the case since sysfs does not implement
a release() method. So kernfs_drain_open_files() will return early.
But there is a good chance that I don't got all kernfs/sysfs details.

Thanks,
//richard