CVE-2026-80553

What it actually does

A use-after-free in the Linux kernel s390 vfio_ccw driver: io_work and crw_work are initialized for a VFIO CCW device but were not cancelled or flushed in the device-release path. After the private device structure is freed, a still-queued or later-dispatched work item can run against dangling kernel pointers. On s390x this corrupts host kernel memory and, given CVSS scope Changed, can affect confidentiality, integrity, and availability of the host kernel from a lesser-privileged local or guest context (local access, low privileges, no user interaction). Impact is limited to IBM Z systems that actually load vfio_ccw for CCW device passthrough.

Why it matters to the business

Relevant only to organizations running Linux on IBM Z (s390x) with VFIO CCW passthrough, typically KVM/QEMU mainframe virtualization. A guest or local user who can open the VFIO CCW device may crash the host or, in a successful exploit, take over the hypervisor—outage of mainframe workloads, tenant isolation failure, and potential host credential or data exposure. This is not in CISA KEV, is not associated with ransomware, has no public exploit, and has a very low EPSS (~0.18%) though the score rose about 36% over 30 days. Non-s390 estates can treat this as not applicable; IBM Z virtualization operators should still patch because host compromise on a mainframe has outsized operational cost.

How an attack unfolds

There is no known in-the-wild exploitation, named threat actor, or public exploit. A realistic path is local: an attacker who already has a foothold on the s390x host, or control of a guest with a passed-through CCW device, uses the VFIO CCW interface so that I/O or channel-report work is queued, then forces device teardown (close, unbind, or mediated-device release) so that work runs after the private struct is freed. The resulting use-after-free is a classic kernel memory-corruption primitive; with further heap shaping it could be turned into privilege escalation or a guest-to-host breakout. Exploitation requires local access, the vfio_ccw driver, and winning a teardown-versus-workqueue race—not remote unauthenticated attack.

How to fix it

Apply the Linux kernel update from your distribution or vendor that includes the s390/vfio_ccw fix which cancels and flushes io_work and crw_work in the device-release path so work cannot run after the private struct is freed. No package-specific fixed versions were supplied with this advisory—use the distro changelog or git history for CVE-2026-80553 / the vfio_ccw workqueue cleanup. If you cannot patch immediately on IBM Z hosts that use CCW passthrough, reduce exposure by removing unused VFIO CCW assignments, restricting who can open vfio_ccw devices, and avoiding untrusted guests on passthrough CCW devices. Systems that are not s390x, or that do not load vfio_ccw, are unaffected.

How to confirm the fix worked

Confirm architecture is s390x and whether vfio_ccw is built or loaded (lsmod, /lib/modules/$(uname -r), kernel config CONFIG_VFIO_CCW). After patching, verify the running kernel changelog or source contains the _release_dev workqueue cancel/cleanup for io_work and crw_work, and that unbind/release of a VFIO CCW device no longer leaves those work items active. On test systems with KASAN or similar, exercise mediated-device create/destroy and I/O plus CRW paths and confirm no use-after-free reports. Inventory guests with CCW passthrough to ensure they run only on patched hosts.

Typical attack path

1. Obtain local access on an s390x Linux host, or control of a guest that has a VFIO CCW device passed through.
2. Confirm the vfio_ccw driver is in use and the attacker can open or control the corresponding VFIO/mdev CCW device.
3. Cause I/O or channel-report (CRW) work to be queued on io_work or crw_work.
4. Trigger device release, unbind, or mediated-device teardown so the private structure is freed while work may still run.
5. When the workqueue callback touches freed memory, convert the use-after-free into host kernel memory corruption.
6. Use that corruption for host denial of service, local privilege escalation, or guest-to-host escape.

How to detect it

There are no public exploits, named campaigns, or unique malware artifacts. Look for evidence the bug was triggered rather than a specific implant: host kernel oops, panic, or KASAN use-after-free on s390x with vfio_ccw on the stack, especially around device unbind, mdev destroy, or guest shutdown with CCW passthrough. Sources: dmesg/journal kernel logs, crash dumps (kdump), hypervisor logs for unexpected guest or host restarts, and audit/udev logs of vfio_ccw device removal. Correlate crashes with recent VFIO CCW teardown. Absence of oops does not prove no exploitation, but with no known exploit a clean kernel log and patched kernel are the practical bar.

• vfio_ccw
• BUG: KASAN: use-after-free
• Workqueue:
• vfio_ccw:

What your security team should do

• Triage by architecture: close as not applicable unless the estate includes Linux on IBM Z with vfio_ccw; treat those hosts as high priority because of host-kernel impact and changed scope.
• Patch s390x kernels to a build that cancels vfio_ccw io_work and crw_work on device release; do not wait for KEV listing given the 8.8 local/guest-to-host rating.
• Until patched, restrict VFIO CCW device access, avoid passthrough to untrusted guests, and limit who can unbind or destroy those devices.
• Hunt historical kernel oops and KASAN reports involving vfio_ccw around device teardown; EPSS is low and exploit maturity is none, so prioritize patching over emergency incident response unless crashes are already present.
• Track distro kernel advisories for the exact fixed package versions and confirm deployment on all s390x hypervisors.