CVE-2026-53116

In the Linux kernel, the following vulnerability has been resolved:

s390/ap: use generic driver_override infrastructure

When the AP masks are updated via apmaskstore() or aqmaskstore(), apbusrevisebindings() is called after apattr_mutex has been released.

This calls _aprevisereserved(), which accesses the driveroverride field without holding any lock, racing against a concurrent driveroverridestore() that may free the old string, resulting in a potential UAF.

Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock.

Note that unlike most other buses, the AP bus does not check driveroverride in its match() callback; the override is checked in apdevice_probe() and __aprevisereserved() instead.

Also note that we do not enable the driveroverride feature of struct bustype, as AP - in contrast to most other buses - passes "" to sysfsemit() when the driveroverride pointer is NULL. Thus, printing "\n" instead of "(null)\n".

Additionally, AP has a custom counter that is modified in the corresponding custom driveroverridestore().