CVE-2026-45981

What it actually does

This is a Linux kernel device-lifecycle bug in the s390 Channel I/O subsystem. In css_alloc_subchannel(), the kernel initializes an embedded struct device and then attempts to configure DMA masks. If DMA mask setup fails, the vulnerable error path frees the subchannel object directly instead of releasing the initialized device through put_device(). Because the Linux device model may still hold references to the embedded device, this can create an invalid object lifetime state, leading to use-after-free or double-free behavior. The primary practical impact is local kernel instability or crash, resulting in denial of service. The CVSS vector indicates local access is required, low attack complexity, low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation could cause affected Linux systems running on s390 architecture to crash or become unstable, disrupting workloads hosted on those systems. The issue is not known to be exploited in the wild, is not listed in CISA KEV, has low EPSS probability, and has no reported public exploit maturity, so it is generally a lower-priority vulnerability than remotely exploitable kernel flaws. However, organizations operating IBM Z or Linux on s390 should still remediate through normal kernel update processes because kernel denial-of-service vulnerabilities can affect service availability, batch processing, and platform reliability.

How an attack unfolds

An attacker must first obtain local access to an affected Linux system with sufficient privileges to trigger code paths that allocate s390 Channel I/O subchannels or otherwise influence device discovery or initialization paths. The attacker then attempts to force or race a failure during DMA mask setup after device_initialize() has already been called. On vulnerable kernels, the error path incorrectly frees the subchannel structure directly rather than dropping the device model reference with put_device(). This leaves the kernel device model with an inconsistent reference state. Subsequent cleanup, reference release, or access to the stale device object can trigger a use-after-free, double-free, kernel oops, panic, or other memory corruption condition. In practical terms, exploitation is most likely to be used for local denial of service rather than data theft or privilege escalation.

How to fix it

Apply the vendor-provided Linux kernel update that contains the s390/cio fix for css_alloc_subchannel() device lifecycle handling. The corrected implementation releases the initialized device with put_device() on the DMA mask setup failure path instead of freeing the subchannel structure directly. Because no exact fixed package versions were provided, use distribution-specific advisories from the Linux distribution or kernel vendor and update to the latest supported kernel for the affected release stream. Prioritize systems running Linux on s390 or IBM Z; non-s390 systems are not expected to exercise this architecture-specific code path. If immediate patching is not possible, reduce local attack surface by limiting shell access, restricting administrative and device-management privileges, preventing untrusted users from running workloads on affected hosts, and applying standard kernel hardening controls. Mitigation should not be considered a substitute for applying the corrected kernel.

How to confirm the fix worked

Confirm whether systems are running on s390 architecture and using an affected kernel build. Validate remediation by checking that the installed kernel package includes the upstream or vendor backport for the s390/cio css_alloc_subchannel() lifecycle fix. After patching, reboot into the updated kernel and verify the active kernel version with standard system tooling such as uname -a and the distribution package manager. Review vendor changelogs or security advisories for references to s390/cio, css_alloc_subchannel(), device_initialize(), put_device(), or DMA mask error-path handling. Where feasible, run regression testing around s390 device discovery and Channel I/O initialization and monitor kernel logs for new oops, panic, KASAN, slab, or device model reference-counting errors.

Typical attack path

1. Gain local authenticated access to an affected Linux system running on s390 architecture.
2. Identify a way to trigger s390 Channel I/O subchannel allocation or device initialization behavior.
3. Cause dma_set_coherent_mask() or dma_set_mask() to fail after device_initialize() has been called.
4. Trigger the vulnerable error path in css_alloc_subchannel().
5. Cause the kernel to free the subchannel object incorrectly while device model references may still exist.
6. Wait for or provoke subsequent device cleanup or reference handling that accesses or frees the stale object.
7. Achieve local denial of service through kernel oops, panic, crash, or system instability.

How to detect it

Look for evidence of local kernel instability on affected s390 systems, especially crashes or kernel warnings involving the Channel I/O subsystem, subchannel allocation, DMA mask setup, or device reference handling. Useful sources include kernel ring buffer output, system journal logs, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, KASAN/KFENCE reports, audit logs for local user activity shortly before a crash, and hypervisor or platform management logs showing abnormal guest termination. Focus on log entries containing css_alloc_subchannel(), s390/cio, subchannel allocation failures, dma_set_coherent_mask(), dma_set_mask(), use-after-free, double-free, slab corruption, kernel BUG, unable to handle kernel paging request, general protection fault, or kernel panic. There are no reliable network indicators for this vulnerability because exploitation is local and kernel-internal. Attribution to exploitation is difficult; correlate suspicious local activity, repeated device initialization failures, and kernel memory errors occurring immediately before system crashes.

• css_alloc_subchannel
• s390/cio
• dma_set_coherent_mask
• dma_set_mask
• use-after-free
• double free
• double-free
• kernel BUG
• kernel panic
• Oops:
• Unable to handle kernel paging request
• general protection fault
• KASAN: use-after-free
• KASAN: slab-out-of-bounds
• BUG: kernel NULL pointer dereference
• slab corruption
• corrupted list
• refcount_t: underflow
• refcount_t: addition on 0
• put_device

What your security team should do

• Inventory Linux systems running on s390 or IBM Z and identify active kernel versions.
• Prioritize patching affected s390 Linux hosts through the normal kernel update and reboot process.
• Confirm the fix is present using vendor advisories, package changelogs, or kernel source/backport references.
• Restrict local interactive access and privileged device-management capabilities on unpatched systems.
• Monitor affected hosts for kernel oops, panic, KASAN, use-after-free, double-free, or s390/cio error messages.
• Treat unexpected crashes on affected s390 systems as potentially security-relevant until kernel logs and crash dumps are reviewed.
• Because this issue is not in KEV and has low EPSS, schedule remediation based on platform criticality, but do not defer indefinitely for production s390 workloads.