s390/cio DriverOverride UAF

Vulnerability analysis

The root cause is that the s390 CIO CSS bus implemented its own driver_override field (const char *driver_override in struct subchannel) and custom sysfs store/show handlers. The css_bus_match() function accessed sch->driver_override without holding the device lock. Since __driver_attach() calls the bus match() callback intentionally without the device lock, a concurrent write to driver_override (via the sysfs store handler, which calls driver_set_override() and frees the old string) can race with the match() read, resulting in a use-after-free on the driver_override string. The fix removes the custom driver_override field and sysfs attribute entirely, instead setting .driver_override = true on the bus_type struct and using the generic device_match_driver_override() helper, which uses the driver-core's properly locked infrastructure (the generic driver_override is stored in struct device and accessed under the device lock by the core). Attack surface is local to s390 hardware, requiring the ability to write to the driver_override sysfs attribute (typically requires root or CAP_SYS_ADMIN) while concurrent driver probing occurs.