Look up another CVE · open CVE-2026-80549 in the interactive tracker
CVE-2026-80549
s390/vfio_ccw: Move cp cleanup out of not operational
Published 2026-08-26 (2 months ago) by the Linux kernel CNA. Subsystem drivers/s390. Debian urgency: not yet assigned.
Debian does not build this code. The per-release build detail is under "Where it lives" below.
What to do, per Debian release
Debian's own status for CVE-2026-80549 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.105-1 | Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
The fsm_notoper() routine is called when the device has been lost, and is (by definition) no longer operational. Since this can happen asynchronously from the normal behavior of the driver, the cleanup may happen when holding other locks in the calling sequence (notably, the cio subchannel lock). Push the cleanup of the private->cp resources to a workqueue, where it can be done out from under that lock sequence and a future patch can safely manage the locking requirements.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/s390/cio/vfio_ccw_drv.c
drivers/s390/cio/vfio_ccw_fsm.c
drivers/s390/cio/vfio_ccw_ops.c
drivers/s390/cio/vfio_ccw_private.h
- What this is
- S390 VFIO-CCW DRIVERMAINTAINERS section matched on drivers/s390/cio/vfio_ccw* · linux-s390@vger.kernel.org · Supported
Check it on the machine
grep -wE 'CONFIG_S390|CONFIG_VFIO_CCW' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code. In 5 releases below, every kernel flavour Debian publishes has the switch off, so the vulnerable file is compiled into no kernel binary Debian ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12n
- n
- not enabled on any flavour - this release does not build the code
- Build switches
- CONFIG_S390, CONFIG_VFIO_CCW
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-08-26 (2 months ago)source
- CVSS
- 8.2 high
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/s390
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.0 | 6.1.185 | c9b85aa2cf73 |
| 6.0 | 6.6.153 | f98a9890ca42 |
| 6.0 | 6.12.105 | 4e3301e2a651 |
| 6.0 | 6.18.46 | af1759d8e6e6 |
| 6.0 | 7.1.10 | 56100baa0eb7 |
| 6.0 | 7.2 | 0c11f61a876e |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Reachable only via local VFIO/mdev device access (pread/pwrite/ioctl on an opened vfio-ccw mediated device); the vulnerable cp_free() runs from FSM not-operational handling triggered by CIO subchannel events and VFIO I/O, not from any network protocol.
- AC:LAttack complexity, low
- A VFIO client can submit channel programs and concurrently provoke not-operational transitions (device close/reset, in-flight I/O, or subchannel state changes), controlling both sides of the race without rare external timing.
- PR:HPrivileges required, high
- Exploitation requires opening and operating an s390 vfio-ccw passthrough mdev, which needs host administrator setup and CAP_SYS_ADMIN-level VFIO/IOMMU access that cannot be obtained from an unprivileged user namespace.
- UI:NUser interaction, none
- No victim interaction is required beyond the attacker already having VFIO device access; triggering the bug is fully automated through concurrent I/O submissions and device state transitions.
- S:CScope, changed
- vfio-ccw manages guest DMA page pinning/unpinning through the IOMMU for channel I/O passthrough; unsynchronized cp_free() under the wrong locks can corrupt that isolation boundary between the VFIO guest and the host kernel.
- C:HConfidentiality impact, high
- Concurrent unsynchronized cp_free() on an active channel_program can double-free or use-after-free kmalloc'd ccwchain/page_array metadata and pinned page state, yielding kernel memory disclosure primitives per UAF guidance.
- I:HIntegrity impact, high
- The same race while unpining guest pages and freeing channel-program structures can corrupt heap metadata and IOMMU mappings, enabling arbitrary kernel write or control-flow hijack per memory-corruption guidance.
- A:HAvailability impact, high
- Calling sleeping vfio_unpin_pages()/cp_free() while holding the subchannel spinlock can deadlock the kernel, and the concurrent double-free/UAF reliably causes kernel oops/panic under load.