UBUNTU-CVE-2026-89956: Use After Free

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.