CVE-2026-89956: s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects
In the Linux kernel, the following vulnerability has been resolved:
s390/vfio-ap: Fix missing lock required to access list of apmatrixmdev objects
In order to traverse or add/remove apmatrixmdev objects in the matrixdev->mdevlist, the matrixdev->guestslock mutex must be held. There are two functions that access the list without holding the mutex:
vfioapmdevprobe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfioapmdevprobe function uses the matrixdev->mdevslock mutex to guard the add of a newly created apmatrixmdev object to the matrixdev->mdevlist. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an apmatrixmdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently.
The adding of an apmatrixmdev object to matrixdev->mdevlist is now guarded by the matrixdev->guestslock which is the correct way to protect against concurrent mdevlist access.
Also removed the following two lines of code because the matrixmdev is allocated via vfioallocdevice macro which uses kzalloc, so reqtrigger and cfgchgtrigger are already zero-initialised when the struct is allocated before the call to vfioregisteremulatediommudev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace.
matrixmdev->reqtrigger = NULL; matrixmdev->cfgchgtrigger = NULL;
vfioapmdevforqueue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The statusshow function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfioapmdevforqueue function which iterates the matrixdev->mdevlist to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrixdev->guestslock mutex must be held.
To fix this, the guestslock mutex is taken prior to taking the matrixdev->mdevslock mutex in the statusshow function. It is taken there rather than the vfioapmdevforqueue function - where it is needed - because it must be taken prior to the mdevslock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevslock is needed there to access fields within the matrixmdev object in that function.
See the vfio-ap-locking.rst in the linux kernel tree.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the Linux kernel s390 vfio-ap subsystem and creating or removing mediated devices are exposed to the affected concurrent access path. The issue concerns the ap_matrix_mdev list managed by matrix_dev.
What conditions are needed to trigger the vulnerability?
A race can occur when one mediated device is being created or removed concurrently with another access to the matrix_dev->mdev_list. The unsafe addition occurred because vfio_ap_mdev_probe used mdevs_lock rather than the guests_lock mutex that protects this list.
What is the potential impact?
Concurrent list access can result in kernel memory corruption or a use-after-free condition.
What does the fix change?
The fix guards addition of ap_matrix_mdev objects to matrix_dev->mdev_list with matrix_dev->guests_lock, the mutex required for list access. It also removes redundant trigger-field initialization because the device allocation path already zero-initializes the object.