Description
In the Linux kernel, the following vulnerability has been resolved:

s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects

In order to traverse or add/remove ap_matrix_mdev objects in the
matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held.
There are two functions that access the list without holding the mutex:

vfio_ap_mdev_probe function
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock
mutex to guard the add of a newly created ap_matrix_mdev object to the
matrix_dev->mdev_list. This mutex does not protect list access; its purpose
is to guard against concurrent access to fields contained in an
ap_matrix_mdev object. This could lead to kernel memory corruption or
use-after-free if another mdev is created or removed concurrently.

The adding of an ap_matrix_mdev object to matrix_dev->mdev_list
is now guarded by the matrix_dev->guests_lock which is the correct
way to protect against concurrent mdev_list access.

Also removed the following two lines of code because the matrix_mdev is
allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger
and cfg_chg_trigger are already zero-initialised when the struct is
allocated before the call to vfio_register_emulated_iommu_dev. This
prevents a window whereby these triggers are set to NULL after
the device is exposed to userspace.

matrix_mdev->req_trigger = NULL;
matrix_mdev->cfg_chg_trigger = NULL;

vfio_ap_mdev_for_queue function
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The status_show function that supports display of the status attribute of
the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue
function which iterates the matrix_dev->mdev_list to find the object
representing the queue device whose status is to be displayed. In order to
traverse this list, the matrix_dev->guests_lock mutex must be held.

To fix this, the guests_lock mutex is taken prior to taking the
matrix_dev->mdevs_lock mutex in the status_show function. It is taken
there rather than the vfio_ap_mdev_for_queue function - where it is
needed - because it must be taken prior to the mdevs_lock mutex in order to
adhere to the proper locking order and prevent a lockdep splat; also
because the mdevs_lock is needed there to access fields within
the matrix_mdev object in that function.

See the vfio-ap-locking.rst in the linux kernel tree.
Published: 2026-09-16
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: Kernel memory corruption / use‑after‑free in s390 vfio‑ap
Action: Update
AI Analysis

Impact

A missing lock protects the list of ap_matrix_mdev objects in the Linux kernel. When a probe or status call accesses the list without holding the proper mutex, concurrent creation or removal of matrix devices can corrupt kernel memory or result in a use‑after‑free of a device structure. This allows an attacker to execute arbitrary code in kernel mode, potentially leading to a privilege escalation or denial of service. The vulnerability is a classic improper synchronization race condition (CWE‑666) that directly impacts kernel integrity.

Affected Systems

All Linux kernel builds that include the s390/vfio‑ap driver, regardless of distribution, are affected until the patch that adds the correct guests_lock around list operations is applied. The vulnerability exists in every kernel variant that has the ap_matrix_mdev list handling code unpatched.

Risk and Exploitability

The EPSS score is below 1 % and the vulnerability is not compiled in CISA’s KEV list, indicating a low current exploitation probability. Nevertheless, because the flaw can lead to arbitrary kernel code execution, it remains a high‑severity threat once the code is present. The attack vector is inferred to be local privilege, requiring the ability to interact with the vfio‑ap device (e.g., by creating or removing a matrix guest).

Generated by OpenCVE AI on September 18, 2026 at 07:28 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version containing the patch that protects the mdev list with the guests_lock mutex
  • If an immediate kernel upgrade is not possible, consider disabling or removing the vfio‑ap module or preventing user space from creating matrix devices to mitigate the risk
  • After applying the fix or disabling the module, reboot to ensure the new lock ordering takes effect

Generated by OpenCVE AI on September 18, 2026 at 07:28 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 03 Oct 2026 11:15:00 +0000

Type Values Removed Values Added
References

Fri, 18 Sep 2026 07:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416
CWE-666

Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex: vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently. The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access. Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace. matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL; vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held. To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function. See the vfio-ap-locking.rst in the linux kernel tree.
Title s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-03T10:56:52.494Z

Reserved: 2026-09-11T19:38:34.778Z

Link: CVE-2026-89956

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:05.920

Modified: 2026-10-03T11:17:44.883

Link: CVE-2026-89956

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T07:30:05Z

Weaknesses
  • CWE-416

    Use After Free

  • CWE-666

    Operation on Resource in Wrong Phase of Lifetime