Re: [BUG] KASAN: slab-use-after-free in _copy_to_user from platform/x86/dell-smbios-wmi

[Armin Wolf <W_Armin@gmx.de>]

Am 15.06.26 um 15:30 schrieb gregkh@linuxfoundation.org:

> On Mon, Jun 15, 2026 at 02:19:16PM +0200, Armin Wolf wrote:
>> Am 14.06.26 um 21:15 schrieb Shuangpeng Bai:
>>
>>> Hi Kernel Maintainers,
>>>
>>> I hit the following report while testing current upstream kernel:
>>>
>>> KASAN: slab-use-after-free in _copy_to_user from platform/x86/dell-smbios-wmi
>>>
>>> on commit: e8c2f9fdadee7cbc75134dc463c1e0d856d6e5c7 (May 25 2026)
>>>
>>> The reproducer and .config files are here.
>>> https://gist.github.com/shuangpengbai/f5b15c099e80897486b4238ddb91df79
>>>
>>> I'm happy to test debug patches or provide additional information.
>> It seems that unbinding the dell-smbios-wmi driver races with any outstanding
>> file operations on the misc device, causing them to access memory already freed
>> by the unbound driver.
> How can that happen if the module reference count is properly
> incremented when the file is open?  Perhaps the driver isn't doing that
> correctly?
>
>> I do not know if the misc device synchronizes file operations against removal,
>> but i do not think that this is the case. I added the maintains of the char drivers
>> to the discussion, maybe they know this.
> Wait, is this a module unload, or a manual "unbind" operation from
> sysfs?  Either way, this something that only root does, and is not part
> of any normal operation that a user can trigger, or should ever be
> doing, so it's kind of "best effort" if it works at all :)
>
> thanks,
>
> greg k-h

Its a "unbind" operation, either from sysfs or started by the WMI driver core.

I do not think that this has something to do with the module reference counter,
because the UAF is triggered by the device state container being freed:

1. devm_kzalloc() + misc_register()
2. open(), uses data previously allocated with devm_kzalloc()
3. unbind, misc_unregister() + freeing of state container data.
4. read(), access to already freed state container data.

I assume that misc_unregister() does not prevent read(), write() and ioctl()
on already opened file descriptors? If yes then i think a RW-lock inside the
driver would be necessary to synchronize the removal of the misc device with
any outstanding read()/ioctl() operations.

Thanks,
Armin Wolf