CVE-2026-53116

What it actually does

This is a race-condition use-after-free in the Linux kernel s390 AP bus handling. When AP queue or adapter masks are changed through sysfs, the AP bus revises device bindings after releasing its attribute mutex. During that revision, kernel code can read a device's driver_override pointer at the same time another sysfs write replaces or frees that string. The result is a kernel memory-safety bug that can lead to a kernel crash and, depending on allocator state, kernel memory corruption. The affected code path is specific to IBM Z/s390 systems using the AP bus, commonly associated with cryptographic adapter/queue management.

Why it matters to the business

Organizations running affected s390 Linux kernels may face host instability or outage if a local user or management process can trigger the race through AP-related sysfs interfaces. Because this is not known to be exploited in the wild, is not in the CISA KEV catalog, has no reported ransomware association, and has a low EPSS score, urgency is lower than for remotely exploitable kernel issues; however, kernel memory corruption in infrastructure hosts should still be remediated through normal kernel patch cycles, especially on systems exposing AP crypto resources or using virtualization/crypto adapter management workflows.

How an attack unfolds

An attacker needs local access to an affected s390 Linux system and permission to write to AP bus sysfs attributes. The attacker repeatedly changes AP adapter or queue masks while concurrently writing to a device driver_override attribute. The mask update causes AP bus binding revision logic to inspect driver_override without the appropriate synchronization. A racing driver_override write can free or replace the string while it is being read, producing a use-after-free. The most likely practical outcome is a kernel oops, panic, or host denial of service. More advanced exploitation would require shaping kernel heap reuse after the freed string and turning the stale pointer dereference into controlled kernel memory corruption, which is highly environment- and configuration-dependent.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the fix replacing the custom AP bus driver_override handling with the generic driver-core driver_override infrastructure, which protects accesses with its internal locking. No product-specific fixed versions were provided in the input, so use the relevant distribution or appliance vendor advisory for the exact package version. As interim mitigation, restrict write access to AP bus sysfs attributes to trusted administrative processes only, limit local shell access on affected s390 hosts, monitor and control privileged automation that changes AP masks, and consider disabling or avoiding unnecessary AP crypto adapter reconfiguration on unpatched systems where operationally feasible.

How to confirm the fix worked

Confirm that the running kernel package is at or above the vendor-fixed version for this issue, not just that an updated package is installed on disk. On source-based or custom kernels, verify that the s390 AP bus uses the generic driver_override infrastructure rather than unsynchronized custom access to the driver_override pointer. Validate exposure by checking whether the system is s390 and has AP bus sysfs entries present, such as /sys/bus/ap/. After patching and rebooting into the fixed kernel, confirm that AP mask changes and driver_override reads/writes function normally and that kernel logs do not show AP bus-related oops, KASAN, use-after-free, or general-protection-fault messages.

Typical attack path

1. Gain local shell or code execution on an affected IBM Z/s390 Linux host.
2. Obtain sufficient privileges to write AP bus sysfs attributes, typically root or an equivalent privileged management context.
3. Identify AP bus devices and writable AP mask attributes under sysfs.
4. Run concurrent writes against AP mask controls such as apmask or aqmask and per-device driver_override attributes.
5. Win the race so AP binding revision reads a driver_override pointer that has just been freed or replaced.
6. Trigger kernel memory corruption, typically resulting in a kernel oops, panic, or system instability.

How to detect it

Look for evidence of prior exploitation or attempted triggering in kernel logs, system journals, audit logs, and endpoint telemetry. Relevant sources include dmesg, /var/log/kern.log, /var/log/messages, systemd journal kernel entries, auditd records for sysfs writes, EDR process command-line telemetry, and shell history for administrative users. Focus on repeated or concurrent writes to AP bus attributes, especially apmask, aqmask, and driver_override, followed by kernel warnings, KASAN reports, use-after-free diagnostics, general protection faults, slab allocator errors, kernel oopses, or reboots. On systems with auditd, search for write/open events against /sys/bus/ap/apmask, /sys/bus/ap/aqmask, and /sys/bus/ap/devices/*/driver_override. A single legitimate AP configuration change is not necessarily suspicious; repeated rapid writes, scripting loops, or changes immediately preceding a crash are more concerning.

• /sys/bus/ap/apmask
• /sys/bus/ap/aqmask
• /sys/bus/ap/devices/*/driver_override
• driver_override_store
• apmask_store
• aqmask_store
• ap_bus_revise_bindings
• __ap_revise_reserved
• BUG: KASAN: use-after-free
• use-after-free in __ap_revise_reserved
• general protection fault
• kernel BUG at drivers/s390/crypto
• Unable to handle kernel pointer dereference
• Oops:
• Call Trace:
• Write to /sys/bus/ap/apmask
• Write to /sys/bus/ap/aqmask
• Write to /sys/bus/ap/devices/
• driver_override

What your security team should do

• Prioritize patching affected IBM Z/s390 Linux hosts that expose AP crypto devices, host virtualization workloads, or allow privileged automation to manage AP masks.
• Inventory systems for /sys/bus/ap/ presence to determine where the vulnerable code path is reachable.
• Restrict root-equivalent access and tightly control automation that writes to /sys/bus/ap/apmask, /sys/bus/ap/aqmask, or /sys/bus/ap/devices/*/driver_override.
• Add monitoring for suspicious or repeated writes to AP bus sysfs attributes, especially concurrent changes to AP masks and driver_override.
• Review kernel logs and audit logs from the period before patching for signs of crashes or AP bus-related memory-safety errors.
• Because public exploit maturity is currently listed as none and EPSS is low, handle through expedited normal kernel maintenance unless local multi-user exposure or high-availability requirements justify emergency patching.