CVE-2026-53117

What it actually does

This is a Linux kernel use-after-free race in the s390 Channel I/O driver matching path. During driver probing through __driver_attach(), the bus match() callback can access a device's driver_override field without holding the device lock. If another path modifies or frees that field at the same time, the kernel may dereference freed memory. The practical impact is most relevant on IBM Z / s390 systems using the affected Channel I/O subsystem and may result in kernel memory corruption, system crash, or potentially local privilege escalation depending on exploitability and heap control.

Why it matters to the business

Organizations running affected Linux kernels on s390 infrastructure could experience unplanned host outages or instability if the flaw is triggered. Because the issue is kernel-level, a successful exploit can affect the entire system rather than a single application. Current public risk signals are low: EPSS is low, the issue is not listed in CISA KEV, it is not known to be used in ransomware campaigns, and no public exploit maturity is reported. However, kernel vulnerabilities should still be prioritized for routine patching, especially on shared, multi-user, or high-availability mainframe Linux environments.

How an attack unfolds

An attacker would need local access or another foothold that allows interaction with the relevant s390 device driver binding interfaces, such as sysfs driver override controls, and the ability to influence driver probe or bind activity. The attacker attempts to race updates to the driver_override state against kernel driver matching performed during __driver_attach(). If the race is won, the match path may read memory after it has been freed. In a simple case, this causes a kernel oops or panic, producing a denial of service. With sufficient kernel heap grooming, knowledge of the target kernel build, and the necessary local permissions, an attacker may attempt to shape the freed memory contents to turn the use-after-free into controlled kernel memory corruption. There is currently no known public exploit or active exploitation associated with this vulnerability.

How to fix it

Apply a Linux kernel update that includes the s390/cio fix switching to the generic driver-core driver_override infrastructure with proper locking. If using a vendor-supported distribution, install the vendor kernel package containing the backported fix rather than relying only on upstream version names. Reboot into the fixed kernel and remove or disable older vulnerable kernels where operationally feasible. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting administrative access to sysfs device binding and driver_override interfaces, preventing untrusted users from performing driver bind/unbind operations, and applying standard hardening controls such as kernel lockdown, least privilege, and workload isolation. Because no affected product list or fixed package versions were provided, use distribution advisories and kernel changelogs to identify the exact fixed build for each platform.

How to confirm the fix worked

Confirm the running system is s390 or uses the s390 Channel I/O subsystem before prioritizing this issue. Verify the active kernel package includes the upstream or vendor backport for the s390/cio driver_override locking change. Confirm the host has been rebooted into the fixed kernel using uname -a, package manager state, and bootloader configuration. Review vendor advisories, changelogs, or source patches for references to using the generic driver_override infrastructure in s390/cio. For exposure validation, inspect whether relevant sysfs driver_override files exist under /sys/bus/ccw/devices/, /sys/bus/css/devices/, or other s390 Channel I/O-related bus paths, and verify only trusted administrative users can write to them.

Typical attack path

1. Gain local access to an affected Linux system running on s390 architecture.
2. Identify writable driver override or device binding interfaces under sysfs for s390 Channel I/O devices.
3. Repeatedly modify driver_override state while triggering driver probe, bind, unbind, or attach operations.
4. Attempt to win the race where __driver_attach() calls the bus match() callback while driver_override is being changed or freed.
5. Cause a kernel use-after-free condition, resulting in system crash or, with advanced exploitation, possible kernel-level code execution or privilege escalation.

How to detect it

Look for evidence of attempted exploitation in kernel logs and administrative activity rather than network telemetry, because this is a local kernel race condition. Review journalctl, dmesg, /var/log/kern.log, /var/log/messages, auditd logs, sudo logs, shell history, and EDR process telemetry for repeated writes to sysfs driver_override files or repeated driver bind/unbind activity on s390 Channel I/O devices. Kernel crash artifacts are especially important: collect kdump/vmcore files, oops traces, KASAN reports, panic logs, and call traces that reference driver_override, __driver_attach(), cio, ccw, css, or s390 bus matching. Also investigate unexplained reboots or panics occurring near administrative commands that write under /sys/bus/*/devices/*/driver_override, /sys/bus/*/drivers/*/bind, or /sys/bus/*/drivers/*/unbind. There are no known public exploit-specific file hashes, command strings, or network indicators for this issue.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• kernel BUG
• Oops:
• Kernel panic
• general protection fault
• __driver_attach
• driver_override
• s390/cio
• /sys/bus/ccw/devices/*/driver_override
• /sys/bus/css/devices/*/driver_override
• /sys/bus/*/drivers/*/bind
• /sys/bus/*/drivers/*/unbind
• echo * > /sys/bus/*/devices/*/driver_override

What your security team should do

• Inventory Linux systems running on s390 architecture and identify kernel versions in use.
• Check vendor advisories for fixed kernel builds containing the s390/cio driver_override locking fix and schedule patching during the next maintenance window.
• Prioritize patching for multi-user systems, shared mainframe Linux environments, and systems where non-administrative users can trigger device bind/unbind or driver override workflows.
• Restrict write access to sysfs driver binding and driver_override interfaces to trusted administrators only.
• Monitor kernel logs for oops, panic, KASAN, or use-after-free messages involving s390 Channel I/O, driver_override, __driver_attach(), or cio code paths.
• If suspicious crashes are observed, preserve kernel logs, vmcore/kdump artifacts, package versions, and recent administrative command history for forensic review.
• Because the vulnerability is not currently in KEV and has low EPSS, treat it as routine-to-medium urgency unless the environment has exposed local multi-user access or high availability requirements.