Re: [BUG] ci_hdrc_add_device -- KASAN slab-out-of-bounds reading a FOREIGN device's platform_data

[Michal Pecio]

On Fri, 28 Aug 2026 08:01:19 +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 27, 2026 at 10:34:56PM -0700, Farhad Alemi wrote:
> >
> >   BUG: KASAN: slab-out-of-bounds in ci_hdrc_add_device+0xb76/0xd10
> >   Read of size 4 at addr ffff88810e9061c8 by task repro/9505
> >   Call Trace:
> >    ci_hdrc_add_device+0xb76/0xd10
> >    ci_hdrc_usb2_probe+0x22d/0x370
> >    platform_probe+0xf9/0x190
> >    really_probe+0x267/0xaf0
> >    __driver_probe_device+0x1e2/0x350
> >    device_driver_attach+0xe0/0x1d0
> >    bind_store+0x1d0/0x220
> >    kernfs_fop_write_iter+0x3af/0x540
> >    vfs_write+0x61d/0xb90
> >    ksys_write+0x150/0x270

This would be more useful with decoded line numbers, like Syzbot does.

But it looks like you don't actually have this hardware and are trying
to bind the driver to a different device by means of 'driver_override'
or 'new_id'. Many others monkeying with this recently, hence...

> But again, stop messing around with root-only sysfs files without
> understanding that you get to keep the broken pieces of the kernel
> if you touch them :)
> 
> thanks,
> 
> greg k-h

And for the record, I still think that focusing on bind/unbind is
misguided because this interface can be used to trigger actual bugs
which would otherwise need connection or reboot cycles to trigger,
and they would still trigger after sufficient wasted time, with same
stack but 'init_module' or 'usb_new_device' instead of 'bind_store'.

Conversely, this splat could as well be caused by a PCI device with
spoofed IDs (think VM). Possibly even by adding a new ID and running
PCI rescan, so no custom VM needed. Too lazy to try it now...

Actual issue is that the kernel doesn't care about working around
platform/pci/insert/other/subsystems anomalies which don't actually
exist in the field, and I think that's what should be communicated.

Regards,
Michal