CVE-2026-89958 in Linux
Résumé
par VulDB • 16/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
s390/vfio-ap : Correction de la déréférence de matrix_mdev->kvm sans vérification préalable de NULL
La structure ap_driver possède deux champs qui sont des pointeurs de fonction vers des rappels (callbacks) :
* .on_config_changed : appelé au début de la fonction d'analyse du bus AP pour notifier le pilote de périphérique que la configuration AP hôte a changé et que les dispositifs AP associés seront ajoutés ou supprimés en conséquence. Cela donne à l'implémenteur une chance d'évaluer les modifications de configuration et d'y répondre avant que les dispositifs associés ne soient ajoutés ou supprimés.
* .on_scan_complete : appelé à la fin de la fonction d'analyse du bus AP pour notifier le pilote de périphérique que la configuration AP hôte a changé et que les dispositifs AP ont été ajoutés ou supprimés en conséquence. Cela donne à l'implémenteur l'opportunité de répondre aux modifications après que les dispositifs associés soient ajoutés ou supprimés.
Ces deux rappels sont implémentés dans le pilote de périphérique vfio_ap via les fonctions vfio_ap_on_cfg_changed et vfio_ap_on_scan_complete respectivement.
Dans la pile d'appels (call stack) de ces deux fonctions de rappel, le mutex matrix_mdev->kvm->lock est acquis sans vérifier si matrix_mdev->kvm est NULL ou non. Si matrix_mdev->kvm n'a jamais été défini, tenter d'acquérir ce verrou déclenchera une déréférence de pointeur NULL (NULL pointer dereference). Ce correctif ajoute des vérifications pour matrix_mdev->kvm == NULL avant l'acquisition du mutex matrix_mdev->kvm->lock.
Notez que le mutex matrix_mdev->kvm->lock pris dans la fonction vfio_ap_mdev_hot_plug_config est déplacé vers la fonction appelante, ainsi que le mutex matrix_dev->mdevs_lock qui y est nécessaire pour accéder aux champs de la structure matrix_mdev. Il n'a guère de sens d'effectuer ce changement en vérifiant si matrix_mdev->kvm est NULL avant d'acquérir le mutex kvm->lock uniquement pour devoir ensuite déplacer cette vérification via un autre correctif, donc cela est fait dans ce correctif.
Il est important de noter les points suivants : 1. Le mutex matrix_dev->guests_lock est acquis au début des deux fonctions de rappel. Cela garantit que matrix_mdev ne sera pas supprimé via la fonction vfio_ap_mdev_remove car celle-ci acquiert également le mutex matrix_dev_guests_lock avant de supprimer l'objet ; ainsi, matrix_mdev restera disponible pendant toute la durée des fonctions de rappel.
2. Le mutex matrix_dev->mdevs_lock doit être acquis pour accéder aux champs au sein de la structure matrix_mdev.
3. Le mutex matrix_mdev->kvm->lock doit être acquis avant le mutex matrix_dev->mdevs_lock afin d'éviter un signal d'erreur lockdep (lockdep splat).
4. Le mutex kvm->lock doit être maintenu lors du branchement à chaud de la configuration AP de l'invité dans sa description d'état SIE via la fonction vfio_ap_mdev_update_guest_apcb.
5. La fonction vfio_ap_mdev_update_guest_apcb vérifie si matrix_mdev->kvm n'est pas NULL avant d'effectuer le branchement à chaud (hot plug) de la configuration AP de l'invité.
If you want to get best quality of vulnerability data, you may have to visit VulDB.