CVE-2026-89958: s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL

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

s390/vfio-ap: Fix dereference matrixmdev->kvm without checking for NULL

The apdriver structure has two fields which are function pointers to callbacks:

.onconfigchanged: called at the start of the AP bus scan function to notify the device driver that the host AP configuration has changed and the associated AP devices will be added or removed accordingly. This gives the implementor a chance to evaluate the configuration changes and respond to them before the associated devices are added or removed.

.onscancomplete: Called at the end of the AP bus scan function to notify the device driver that the host AP configuration has changed and the AP devices have been added or removed accordingly. This gives the implementor the opportunity to respond to the changes after the associated devices are added or removed.

These two callbacks are implemented in the vfioap device driver via the vfioaponcfgchanged and vfioaponscancomplete functions respectively.

Within the call stack of these two callback functions the matrixmdev->kvm->lock mutex is taken without checking whether matrixmdev->kvm is NULL or not. If matrixmdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrixmdev->kvm == NULL before taking the matrixmdev->kvm->lock mutex.

Note that the matrixmdev->kvm->lock mutex taken in the vfioapmdevhotplugconfig function is moved to the calling function along with the matrixdev->mdevslock which is needed there to access the fields of the matrixmdev. It makes little sense to make the change the check for matrixmdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch.

It is important to make note of the following: 1. The matrixdev->guestslock is acquired at the start of both callback functions. This ensures that matrixmdev will not be removed via the vfioapmdevremove function because it too takes matrixdevguestslock before removing the object; so, matrixmdev will be available for the duration of the callback functions.

2. The matrixdev->mdevslock mutex must be taken in order to access fields within the matrixmdev structure

3. matrixmdev->kvm->lock mutex must be taken before the matrixdev->mdevslock to prevent a lockdep splat.

4: The kvm->lock must be held while plugging the guest's AP configuration into its SIE state description via the vfioapmdevupdateguestapcb function.

5. The vfioapmdevupdateguestapcb checks matrixmdev->kvm to verify it is not NULL before doing the hot plug of the guest's AP configuration.