CVE-2026-89956 in Linux
Summary
by MITRE • 09/16/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified in the s390 VFIO AP subsystem involves a critical concurrency flaw related to improper mutex usage when accessing shared data structures. Specifically, the matrix_dev->mdev_list, which maintains a collection of ap_matrix_mdev objects representing mediated devices for cryptographic adapters, was being accessed without holding the required guests_lock mutex. This oversight creates a race condition where concurrent modifications to the list can occur while it is being traversed or modified by other threads. The vulnerability stems from two distinct code paths that failed to adhere to the established locking protocol defined in the kernel documentation file vfio-ap-locking.rst, leading to potential instability and security risks within the virtualization infrastructure.
The first instance of this flaw exists within the vfio_ap_mdev_probe function, which is responsible for initializing new mediated devices. In its original implementation, this function utilized the matrix_dev->mdevs_lock mutex when adding a newly created ap_matrix_mdev object to the mdev_list. However, the semantic purpose of the mdevs_lock is strictly limited to guarding against concurrent access to specific fields within an individual ap_matrix_mdev structure, not for protecting the integrity of the list itself. By using the wrong lock, the code left the list unprotected during insertion operations. This mismatch allows other threads that are correctly holding or attempting to acquire the guests_lock to modify the same list simultaneously, resulting in a classic race condition. Such concurrency issues can lead to severe kernel memory corruption, including heap overwrites or structural inconsistencies within the linked list nodes.
The operational impact of this vulnerability is significant for systems relying on s390 virtualization with cryptographic pass-through capabilities. If an attacker or a buggy driver triggers concurrent device creation and removal operations while status information is being queried, the resulting race condition can cause use-after-free errors. A use-after-free scenario occurs when memory associated with a removed object is accessed because the list traversal has not yet completed its iteration over that node. This can lead to kernel panics, denial of service conditions for virtual machines utilizing these devices, or potentially arbitrary code execution if an attacker can carefully craft timing attacks to exploit the corrupted pointers and execute malicious payloads within the kernel space.
The second affected area involves the status_show function in sysfs, which displays device status attributes under /sys/bus/ap/devices. This function calls vfio_ap_mdev_for_queue to iterate through the mdev_list to locate specific queue devices for reporting their state. Similar to the probe function, this traversal was performed without holding the guests_lock mutex. To rectify this while maintaining strict lock ordering rules required by the kernel's lock dependency validator (lockdep), the fix implements a nested locking strategy in status_show. The code now acquires the matrix_dev->guests_lock before acquiring the matrix_dev->mdevs_lock. This specific order is mandated to prevent deadlocks and avoid triggering lockdep splats, which indicate potential circular dependencies or incorrect nesting of locks that could compromise system stability under high contention scenarios.
In addition to fixing the locking mechanisms, the patch addresses a minor but logically redundant code segment within vfio_ap_mdev_probe. The original implementation explicitly set matrix_mdev->req_trigger and matrix_mdev->cfg_chg_trigger fields to NULL after allocation. This step was unnecessary because the ap_matrix_mdev structure is allocated using the vfio_alloc_device macro, which internally utilizes kzalloc for memory allocation. Since kzalloc zero-initializes all bytes in the allocated memory block, these trigger pointers are already set to NULL upon creation. Removing this redundant assignment eliminates a small window of vulnerability where the triggers were briefly non-NULL before being reset, although the primary security benefit comes from correcting the locking semantics rather than removing dead code.
From a classification perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization. The failure to use the correct mutex for list access is a textbook example of insufficient synchronization leading to race conditions. Furthermore, in the context of the MITRE ATT&CK framework, this flaw relates to techniques involving resource manipulation and potential privilege escalation if an attacker can leverage the resulting kernel instability or memory corruption to gain unauthorized control over system resources. The vulnerability highlights the importance of adhering strictly to locking hierarchies and understanding the specific scope of each mutex in complex subsystems like VFIO AP.
Mitigation for this issue requires applying the upstream Linux kernel patch that corrects the lock acquisition order in vfio_ap_mdev_probe and status_show functions. System administrators managing s390 virtualization environments should ensure their kernels are updated to versions containing these fixes. For organizations unable to immediately update, monitoring system logs for kernel panics or oops messages related to VFIO AP devices can serve as an indicator of exploitation attempts. Additionally, enforcing strict coding standards that mandate the use of designated locks for specific data structures during code reviews can prevent similar concurrency bugs in future development cycles.