Linux Kernel EUVD-2026-80557

Requires the s390 vfio-ap driver in use with a KVM guest assigned AP crypto resources via an mdev, AND a host-side operation that removes the LAST assigned AP adapter, domain, or control domain from the host's AP configuration - that specific 'resulting bitmap becomes empty' case is what triggers the skipped guest APCB update. Limiting factors: exploitation is confined to IBM Z / s390 hardware with crypto adapters (CEX cards) configured for guest passthrough; it is local-only (AV:L), needs privileged host management access to alter the AP configuration, and the guest does not initiate the flaw - it passively retains access. There is no remote or unauthenticated path and no user-interaction vector.

This is a functional/isolation logic bug in the s390 vfio-ap crypto passthrough driver, not a memory-corruption or remote-code-execution flaw. The vendor CVSS of 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) substantially overstates real-world risk. There is NO EPSS score, NO CISA KEV listing, and NO public exploit identified - signals that align far better with a low-urgency internal correctness fix than with a critical, actively-exploited vulnerability. Crucially, the condition is not attacker-triggered: it arises when a host operator removes the LAST AP adapter, domain, or control domain from the host AP configuration, at which point a bitmap_andnot() return-value misuse causes the guest APCB update to be skipped, leaving the KVM guest with stale hardware access to the now-'removed' AP device. The C:H/I:H/A:H claim is unsupported - the actual impact is bounded, unauthorized crypto-device access retained by an already-privileged guest, with no availability/DoS component. The PR:L rating is questionable: reaching this path requires privileged host-side manipulation of the AP configuration (PR:H). The vendor CVSS attack complexity/privilege signals conflict with the description - verify PR level with vendor, as this is an operator-dependent isolation gap rather than a low-privilege remote exploit.

A host administrator removes the last AP crypto adapter or domain assigned to a guest's mdev from the host AP configuration (e.g. to reassign the crypto resource to a different guest), expecting the device to be hot-unplugged. Due to the bitmap_andnot() return-value bug the guest's shadow APCB is never pushed to KVM, so the guest silently retains hardware access to the crypto device it should no longer reach, breaking isolation between the guest and reassigned/removed crypto resources. No public exploit code exists and this requires the specific host management action to occur.