CVE-2026-53116
N/A
Summary
In the Linux kernel, the following vulnerability has been resolved:
s390/ap: use generic driver_override infrastructure
When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released.
This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() 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 driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead.
Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n".
Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store().
Affected Software
| Vendor | Product | Version Range | Status |
|---|---|---|---|
| Linux | Linux | d38a87d7c0643db61e7a3bfc3ebeea2dc2568f7e < 8f2eca0570438b94602da1297353eb7b10dcb6cb | affected |
| Linux | Linux | d38a87d7c0643db61e7a3bfc3ebeea2dc2568f7e < 81d6f7c3a70b10ff757ee8b5f8114a190871cf1e | affected |
| Linux | Linux | 6.19 | affected |
| Linux | Linux | 0 < 6.19 | unaffected |
| Linux | Linux | 7.0.10 <= 7.0.* | unaffected |
| Linux | Linux | 7.1 <= * | unaffected |
Weaknesses
References
- https://git.kernel.org/stable/c/8f2eca0570438b94602da1297353eb7b10dcb6cb
- https://git.kernel.org/stable/c/81d6f7c3a70b10ff757ee8b5f8114a190871cf1e
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.