CVE-2024-26620: s390/vfio-ap: always filter entire AP matrix
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: always filter entire AP matrix
The vfio_ap_mdev_filter_matrix function is called whenever a new adapter or
domain is assigned to the mdev. The purpose of the function is to update
the guest's AP configuration by filtering the matrix of adapters and
domains assigned to the mdev. When an adapter or domain is assigned, only
the APQNs associated with the APID of the new adapter or APQI of the new
domain are inspected. If an APQN does not reference a queue device bound to
the vfio_ap device driver, then it's APID will be filtered from the mdev's
matrix when updating the guest's AP configuration.
Inspecting only the APID of the new adapter or APQI of the new domain will
result in passing AP queues through to a guest that are not bound to the
vfio_ap device driver under certain circumstances. Consider the following:
guest's AP configuration (all also assigned to the mdev's matrix):
14.0004
14.0005
14.0006
16.0004
16.0005
16.0006
unassign domain 4
unbind queue 16.0005
assign domain 4
When domain 4 is re-assigned, since only domain 4 will be inspected, the
APQNs that will be examined will be:
14.0004
16.0004
Since both of those APQNs reference queue devices that are bound to the
vfio_ap device driver, nothing will get filtered from the mdev's matrix
when updating the guest's AP configuration. Consequently, queue 16.0005
will get passed through despite not being bound to the driver. This
violates the linux device model requirement that a guest shall only be
given access to devices bound to the device driver facilitating their
pass-through.
To resolve this problem, every adapter and domain assigned to the mdev will
be inspected when filtering the mdev's matrix.
Security readout for executives and security teams
Plain-English summary
CVE-2024-26620 affects Linux on IBM s390 systems using vfio-ap to pass cryptographic AP queues into guests. Under specific reconfiguration conditions, a guest could receive access to an AP queue not currently bound to the vfio-ap driver, breaking the expected device isolation model.
Executive priority
Treat as a targeted virtualization isolation issue for s390 cryptographic queue pass-through. Prioritize if those systems support sensitive workloads or multi-tenant guests; otherwise business urgency is limited.
Technical view
The flaw is in s390 vfio-ap matrix filtering. When assigning an adapter or domain to a mediated device, older logic inspected only newly affected APQNs. That could miss previously assigned queues whose binding state changed, allowing unbound AP queues to remain in the guest AP configuration. The fix filters the entire assigned adapter/domain matrix.
Likely exposure
Exposure appears limited to Linux s390 environments using vfio-ap mediated devices for AP queue pass-through. General Linux servers, desktops, and non-s390 systems are not indicated as affected by the supplied sources.
Exploitation context
The sources do not report active exploitation, and CISA KEV is false. The described condition depends on vfio-ap AP pass-through configuration changes and queue binding state. No remote unauthenticated exploitation path is supported by the supplied evidence.
Researcher notes
The issue is correctness and isolation in vfio-ap matrix filtering, not a broadly reachable network bug. Evidence lacks CVSS, CWE, exploit reports, or vendor-specific package status. Version and fix assessment should be tied to distro backports.
Mitigation direction
Update affected s390 Linux kernels to builds containing the referenced stable fixes.
Check Linux distribution advisories for backported vfio-ap fixes and supported kernel versions.
Inventory systems using vfio-ap mediated devices and AP queue pass-through.
Restrict vfio-ap reconfiguration to trusted administrators until patched.
Validation and detection
Confirm whether hosts are IBM s390 systems running Linux with vfio-ap enabled.
Review kernel package changelogs for CVE-2024-26620 or the referenced stable commits.
Verify AP queue pass-through configurations after patching behave according to the Linux device model.
Check vulnerability scanners against actual kernel backport status, not only upstream version numbers.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-26620 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.