Odebrany

CVE-2026-89958

opublikowano: 16.09.2026, 13:17

modyfikacja: 16.09.2026, 13:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

s390/vfio-ap: Napraw dereferencję matrix_mdev->kvm bez sprawdzania NULL

Struktura ap_driver ma dwa pola, na które są wskaźnikami funkcji
wywołania zwrotne:

* .on_config_changed: wywoływany na początku funkcji skanowania magistrali AP
powiadom sterownik urządzenia, że punkt dostępowy hosta
konfiguracja uległa zmianie i powiązany punkt dostępowy
urządzenia zostaną odpowiednio dodane lub usunięte. To
daje realizującemu szansę na ocenę
zmiany konfiguracji i reaguj na nie wcześniej
powiązane urządzenia zostaną dodane lub usunięte.

* .on_scan_complete: Wywoływany na końcu funkcji skanowania magistrali AP
powiadom sterownik urządzenia, że punkt dostępowy hosta
konfiguracja uległa zmianie, podobnie jak urządzenia AP
odpowiednio dodane lub usunięte. To daje
realizatorowi możliwość ustosunkowania się do
zmiany po dodaniu powiązanych urządzeń lub
usunięte.

Te dwa wywołania zwrotne są zaimplementowane w sterowniku urządzenia vfio_ap poprzez
odpowiednio funkcje vfio_ap_on_cfg_changed i vfio_ap_on_scan_complete.

W stosie wywołań tych dwóch funkcji wywołania zwrotnego
matrix_mdev->kvm->lock mutex jest pobierany bez sprawdzania, czy
matrix_mdev->kvm ma wartość NULL lub nie. Jeżeli matrix_mdev->kvm nie została nigdy ustawiona,
próba przejęcia blokady spowoduje wyłuskanie wskaźnika NULL. Ta łatka
dodaje kontrole matrix_mdev->kvm == NULL przed wykonaniem
matrix_mdev->kvm->zablokuj mutex.

Należy zauważyć, że muteks matrix_mdev->kvm->lock pobrany z pliku
Funkcja vfio_ap_mdev_hot_plug_config została przeniesiona do funkcji wywołującej
wraz z matrix_dev->mdevs_lock, który jest tam potrzebny, aby uzyskać dostęp
pola matrix_mdev. Wprowadzanie zmian nie ma większego sensu
sprawdź tam matrix_mdev->kvm przed skorzystaniem z kvm->lock
mutex tylko po to, aby przenieść go przez inną łatkę, więc jest to zrobione
tę poprawkę.

Ważne jest, aby zwrócić uwagę na następujące kwestie:
1. Matrix_dev->guests_lock jest pobierany na początku obu wywołań zwrotnych
funkcje. Gwarantuje to, że matrix_mdev nie zostanie usunięty przez plik
vfio_ap_mdev_remove, ponieważ ona również wymaga matrix_dev_guests_lock
przed usunięciem obiektu; więc matrix_mdev będzie dostępny dla
czas trwania funkcji wywołania zwrotnego.

2. Aby uzyskać dostęp, należy pobrać muteks matrix_dev->mdevs_lock
pola w strukturze matrix_mdev

3. matrix_mdev->kvm->lock mutex musi zostać wzięty przed
matrix_dev->mdevs_lock, aby zapobiec blokadzie.

4: Podczas podłączania konfiguracji AP gościa należy trzymać blokadę kvm->
do opisu stanu SIE poprzez plik vfio_ap_mdev_update_guest_apcb
funkcja.

5. vfio_ap_mdev_update_guest_apcb sprawdza matrix_mdev->kvm, aby to zweryfikować
nie ma wartości NULL przed wykonaniem podłączania podczas pracy konfiguracji AP gościa.

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

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

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

* .on_config_changed: 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.

* .on_scan_complete: 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 vfio_ap device driver via the
vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively.

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

Note that the matrix_mdev->kvm->lock mutex taken in the
vfio_ap_mdev_hot_plug_config function is moved to the calling function
along with the matrix_dev->mdevs_lock which is needed there to access
the fields of the matrix_mdev. It makes little sense to make the change
the check for matrix_mdev->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 matrix_dev->guests_lock is acquired at the start of both callback
functions. This ensures that matrix_mdev will not be removed via the
vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock
before removing the object; so, matrix_mdev will be available for the
duration of the callback functions.

2. The matrix_dev->mdevs_lock mutex must be taken in order to access
fields within the matrix_mdev structure

3. matrix_mdev->kvm->lock mutex must be taken before the
matrix_dev->mdevs_lock 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 vfio_ap_mdev_update_guest_apcb
function.

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

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve