CVE-2024-26620 - s390/vfio-ap Matrix Filtering Flaw in Linux Kernel

The Linux kernel is a huge and complex project, and sometimes the things that go wrong come from small details that are easy to overlook. One recent bug, CVE-2024-26620, is a great example. This vulnerability, fixed in early 2024, affects the IBM s390 mainframe platform and its pass-through support for cryptographic adapters, known as vfio-ap. This long read explains what went wrong, why it’s important, and how attackers could have used it.

What is CVE-2024-26620?

CVE-2024-26620 is a security vulnerability in the Linux kernel’s s390/vfio-ap driver code — specifically in the way it filters cryptographic queue devices (APQNs) during assignment to guest virtual machines (VMs) under KVM (Kernel Virtual Machine).

In plain terms

When passing special hardware (like crypto adapters) through to KVM guests on IBM mainframes, Linux must make sure only devices bound to the right driver can get through. But a bug in the filtering logic meant that, under certain circumstances, unassigned or unbound devices could still be made available to a guest, opening up a possible security hole.

Why Does This Matter?

In cloud or shared environments, strong device isolation is critical for security. If a guest sees or uses a cryptographic adapter it shouldn’t, that guest might:

Break compliance requirements

The Linux device model promises that “a guest shall only be given access to devices bound to the device driver facilitating their pass-through.” This vulnerability broke that promise.

Technical Details

Let’s look at the core issue through example and code.

What’s an APQN?

An APQN (Adapter/Queue Number) denotes a combination of a crypto adapter (APID) and a queue (APQI). For example, 14.0004 is adapter 14, queue 4. The matrix is a list of APQNs assigned to a guest VM.

The Filtering Problem

The Linux function vfio_ap_mdev_filter_matrix() was supposed to remove any APQNs from the guest’s matrix that don’t reference a queue device currently bound to the vfio_ap driver.

BUT: When adding an adapter (APID) or domain (APQI), the code only checked APQNs with the new adapter or domain — not the full set. That means dead or unbound APQNs could stay in the matrix and leak through.

Suppose a guest has this AP matrix

Re-assign domain 4

When domain 4 is re-assigned, the code only checks 14.0004 and 16.0004. Since everyone else is ignored, 16.0005 (which is unbound) gets passed through to the guest—breaking isolation.

Here’s a simplified version of the filtering logic (before the fix)

void vfio_ap_mdev_filter_matrix(struct vfio_ap_matrix_mdev *matrix, int new_adapter, int new_domain)
{
    // Only filter APQNs with new_adapter or new_domain
    for (int i = ; i < matrix->num_apqns; i++) {
        if (matrix->apqns[i].adapter == new_adapter ||
            matrix->apqns[i].domain == new_domain) {
            if (!is_bound_to_vfio_ap(matrix->apqns[i])) {
                // Mark for removal
            }
        }
    }
    // Doesn't filter everything!
}

Problem: Only APQNs with the new adapter/domain are checked, not the full matrix.

The Fix

The patch fixes this by filtering the entire AP matrix every time. Now, whenever a change is made, all APQNs are checked and unbound ones are removed.

Fixed logic

void vfio_ap_mdev_filter_matrix(struct vfio_ap_matrix_mdev *matrix)
{
    for (int i = ; i < matrix->num_apqns; i++) {
        if (!is_bound_to_vfio_ap(matrix->apqns[i])) {
            // Remove from matrix
        }
    }
}

Key Change: No more shortcutting or partial checking. Everything is verified every time, restoring the device model guarantees.

You can review the original patch in the Linux kernel mailing list

- s390/vfio-ap: always filter entire AP matrix
- Linux kernel commit

Can This Be Exploited?

Yes, but the real world risk is limited to s390 systems running KVM with vfio-ap and multi-tenant guests. Exploitation requires:

- Administrative access to assign/unassign AP devices/queues,
- A scenario where a queue is unbound after assignment but before re-assignment—thus sneaking a device through inadvertently.

An attacker with enough privileges and control could potentially gain hardware access their guest shouldn’t have, violating isolation.

Unbind an AP queue from vfio_ap after assignment (maybe via a buggy management interface).

2. When domain/apid is re-added, triggers the matrix refresh.
3. Their guest now gets access to a queue it shouldn’t, possibly snooping or jamming operations meant for another domain.

While this requires insider or high privilege in the virtualization stack, it’s a violation of the kernel’s guarantees. Environments like banking or confidential clouds, where crypto hardware matters, could be at risk.

Fix Status

Patch is public and merged. Update your kernel to the latest 6.8+ release, or backport the fix if on a maintained LTS branch.

- Linux stable patch reference (search for CVE-2024-26620)

Conclusion

CVE-2024-26620 may seem obscure if you’re not a mainframe admin, but it’s a great reminder: security boundaries often fail at the seams—in this case, the seam between device assignment and driver binding. A careful review, good test cases, and timely patching are crucial, especially in shared hardware environments.

Timeline

Published on: 03/11/2024 18:15:19 UTC
Last modified on: 02/14/2025 16:39:02 UTC

CVE-2024-26620 - s390/vfio-ap Matrix Filtering Flaw in Linux Kernel – Full Analysis & Exploit Details