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

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

[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.

Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>

[   92.502430][ T8394] BUG: KASAN: slab-use-after-free in _copy_to_user (include/linux/instrumented.h:129 include/linux/uaccess.h:205 lib/usercopy.c:26)
[   92.504528][ T8394] Read of size 8 at addr ffff888126eec360 by task dell_smbios_wmi/8394
[   92.506899][ T8394] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   92.506905][ T8394] Call Trace:
[   92.506914][ T8394]  <TASK>
[   92.506919][ T8394]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
[   92.506931][ T8394]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
[   92.506956][ T8394]  kasan_report (mm/kasan/report.c:595)
[   92.506972][ T8394]  kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
[   92.506979][ T8394]  _copy_to_user (include/linux/instrumented.h:129 include/linux/uaccess.h:205 lib/usercopy.c:26)
[   92.506986][ T8394]  simple_read_from_buffer (include/linux/uaccess.h:236 fs/libfs.c:1155)
[   92.506998][ T8394]  vfs_read (fs/read_write.c:572)
[   92.507049][ T8394]  ksys_read (fs/read_write.c:717)
[   92.507072][ T8394]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[   92.507095][ T8394]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[   92.507163][ T8394]  </TASK>
[   92.530149][ T8394] Freed by task 8394 on cpu 0 at 92.299564s:
[   92.530733][ T8394]  kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
[   92.531183][ T8394]  kasan_save_free_info (mm/kasan/generic.c:584)
[   92.531673][ T8394]  __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
[   92.532133][ T8394]  kfree (include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
[   92.532509][ T8394]  devres_release_all (drivers/base/devres.c:50 drivers/base/devres.c:547 drivers/base/devres.c:576)
[   92.533000][ T8394]  device_release_driver_internal (drivers/base/dd.c:598 drivers/base/dd.c:1357 drivers/base/dd.c:1375)
[   92.533574][ T8394]  unbind_store (drivers/base/bus.c:244)
[   92.534021][ T8394]  kernfs_fop_write_iter (fs/kernfs/file.c:352)
[   92.534531][ T8394]  vfs_write (fs/read_write.c:595 fs/read_write.c:688)
[   92.534950][ T8394]  ksys_write (fs/read_write.c:740)
[   92.535364][ T8394]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
[   92.535811][ T8394]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
[   92.536610][ T8394] The buggy address belongs to the object at ffff888126eec300
[   92.536610][ T8394]  which belongs to the cache kmalloc-192 of size 192
[   92.537941][ T8394] The buggy address is located 96 bytes inside of
[   92.537941][ T8394]  freed 192-byte region [ffff888126eec300, ffff888126eec3c0)


Best,
Shuangpeng

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

[Armin Wolf]

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.

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.

Thanks,
Armin Wolf

>
> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
>
> [   92.502430][ T8394] BUG: KASAN: slab-use-after-free in _copy_to_user (include/linux/instrumented.h:129 include/linux/uaccess.h:205 lib/usercopy.c:26)
> [   92.504528][ T8394] Read of size 8 at addr ffff888126eec360 by task dell_smbios_wmi/8394
> [   92.506899][ T8394] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [   92.506905][ T8394] Call Trace:
> [   92.506914][ T8394]  <TASK>
> [   92.506919][ T8394]  dump_stack_lvl (lib/dump_stack.c:94 lib/dump_stack.c:120)
> [   92.506931][ T8394]  print_report (mm/kasan/report.c:378 mm/kasan/report.c:482)
> [   92.506956][ T8394]  kasan_report (mm/kasan/report.c:595)
> [   92.506972][ T8394]  kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
> [   92.506979][ T8394]  _copy_to_user (include/linux/instrumented.h:129 include/linux/uaccess.h:205 lib/usercopy.c:26)
> [   92.506986][ T8394]  simple_read_from_buffer (include/linux/uaccess.h:236 fs/libfs.c:1155)
> [   92.506998][ T8394]  vfs_read (fs/read_write.c:572)
> [   92.507049][ T8394]  ksys_read (fs/read_write.c:717)
> [   92.507072][ T8394]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> [   92.507095][ T8394]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> [   92.507163][ T8394]  </TASK>
> [   92.530149][ T8394] Freed by task 8394 on cpu 0 at 92.299564s:
> [   92.530733][ T8394]  kasan_save_track (mm/kasan/common.c:57 mm/kasan/common.c:78)
> [   92.531183][ T8394]  kasan_save_free_info (mm/kasan/generic.c:584)
> [   92.531673][ T8394]  __kasan_slab_free (mm/kasan/common.c:253 mm/kasan/common.c:285)
> [   92.532133][ T8394]  kfree (include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566)
> [   92.532509][ T8394]  devres_release_all (drivers/base/devres.c:50 drivers/base/devres.c:547 drivers/base/devres.c:576)
> [   92.533000][ T8394]  device_release_driver_internal (drivers/base/dd.c:598 drivers/base/dd.c:1357 drivers/base/dd.c:1375)
> [   92.533574][ T8394]  unbind_store (drivers/base/bus.c:244)
> [   92.534021][ T8394]  kernfs_fop_write_iter (fs/kernfs/file.c:352)
> [   92.534531][ T8394]  vfs_write (fs/read_write.c:595 fs/read_write.c:688)
> [   92.534950][ T8394]  ksys_write (fs/read_write.c:740)
> [   92.535364][ T8394]  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> [   92.535811][ T8394]  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> [   92.536610][ T8394] The buggy address belongs to the object at ffff888126eec300
> [   92.536610][ T8394]  which belongs to the cache kmalloc-192 of size 192
> [   92.537941][ T8394] The buggy address is located 96 bytes inside of
> [   92.537941][ T8394]  freed 192-byte region [ffff888126eec300, ffff888126eec3c0)
>
>
> Best,
> Shuangpeng
>

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

[gregkh]

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

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

[Arnd Bergmann]

On Mon, Jun 15, 2026, at 15:30, gregkh@linuxfoundation.org wrote:
> 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?

It's not, and I think in addition, the probe function needs to
take a reference on the wmi_device do that does not go away while
the misc device exists.

      Arnd

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@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

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

[Arnd Bergmann]

On Mon, Jun 15, 2026, at 22:21, Armin Wolf wrote:
> Am 15.06.26 um 15:30 schrieb gregkh@linuxfoundation.org:
>
> 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,

The misc_device reference count. The module reference count is
protected by the wmi_driver object.

> 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.

A get_device() in ->open() should prevent the misc_device from
going away during read() and ioctl(). You need to put_device() in
->release() then.

If the driver->probe() function takes a reference on the wmi_device,
that prevents it from going away underneath the misc_device.

      Arnd

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

[Armin Wolf]

Am 15.06.26 um 23:00 schrieb Arnd Bergmann:

> On Mon, Jun 15, 2026, at 22:21, Armin Wolf wrote:
>> Am 15.06.26 um 15:30 schrieb gregkh@linuxfoundation.org:
>>
>> 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,
> The misc_device reference count. The module reference count is
> protected by the wmi_driver object.
>
>> 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.
> A get_device() in ->open() should prevent the misc_device from
> going away during read() and ioctl(). You need to put_device() in
> ->release() then.
>
> If the driver->probe() function takes a reference on the wmi_device,
> that prevents it from going away underneath the misc_device.
>
>        Arnd

IMHO this is not the problem here, the issue is that file operations
continue to access struct wmi_smbios_priv even after misc_unregister()
was called during driver unbind.

The UAF is not the WMI or the misc device, it is the driver state container.

Thanks,
Armin Wolf

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

[Greg Kroah-Hartman]

On Tue, Jun 16, 2026 at 12:28:05AM +0200, Armin Wolf wrote:
> Am 15.06.26 um 23:00 schrieb Arnd Bergmann:
> 
> > On Mon, Jun 15, 2026, at 22:21, Armin Wolf wrote:
> > > Am 15.06.26 um 15:30 schrieb gregkh@linuxfoundation.org:
> > > 
> > > 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,
> > The misc_device reference count. The module reference count is
> > protected by the wmi_driver object.
> > 
> > > 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.
> > A get_device() in ->open() should prevent the misc_device from
> > going away during read() and ioctl(). You need to put_device() in
> > ->release() then.
> > 
> > If the driver->probe() function takes a reference on the wmi_device,
> > that prevents it from going away underneath the misc_device.
> > 
> >        Arnd
> 
> IMHO this is not the problem here, the issue is that file operations
> continue to access struct wmi_smbios_priv even after misc_unregister()
> was called during driver unbind.
> 
> The UAF is not the WMI or the misc device, it is the driver state container.

Yes, this is the "classic" issue that the many revisions and discussions
around the "revocable" patch series was attempting to resolve.  Look at
the discussions on the lists for this, and the cros_ec_chardev patch
series for ways to potentially resolve this.

In other words, it's a well known problem, and people are working on it,
but it will take work for each driver to resolve it.  For
non-removable-bus devices, it's not a big deal as this can not happen in
the real world, so don't worry too much about it now.

thanks,

greg k-h