CVE-2026-53116

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ap: use generic driver_override infrastructure<br /> <br /> When the AP masks are updated via apmask_store() or aqmask_store(),<br /> ap_bus_revise_bindings() is called after ap_attr_mutex has been<br /> released.<br /> <br /> This calls __ap_revise_reserved(), which accesses the driver_override<br /> field without holding any lock, racing against a concurrent<br /> driver_override_store() that may free the old string, resulting in a<br /> potential UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure, which<br /> protects all accesses with an internal spinlock.<br /> <br /> Note that unlike most other buses, the AP bus does not check<br /> driver_override in its match() callback; the override is checked in<br /> ap_device_probe() and __ap_revise_reserved() instead.<br /> <br /> Also note that we do not enable the driver_override feature of struct<br /> bus_type, as AP - in contrast to most other buses - passes "" to<br /> sysfs_emit() when the driver_override pointer is NULL. Thus, printing<br /> "\n" instead of "(null)\n".<br /> <br /> Additionally, AP has a custom counter that is modified in the<br /> corresponding custom driver_override_store().