PT-2026-52010 · Linux · Linux
Published
2026-06-24
·
Updated
2026-06-24
·
CVE-2026-53116
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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
"
" instead of "(null)
".
Additionally, AP has a custom counter that is modified in the
corresponding custom driver override store().
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux