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

[Armin Wolf]

Am 15.06.26 um 15:30 schrieb gregkh@xxxxxxxxxxxxxxxxxxx:

> 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