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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

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