Odebrany

CVE-2026-98473

opublikowano: 18.10.2026, 18:16

modyfikacja: 19.10.2026, 12:18

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 KVM GISC i wyciek strony po usunięciu kolejki z konfiguracji hosta

W obsłudze przerwań i stron KVM występują trzy powiązane problemy
zasobów po usunięciu kolejki z konfiguracji AP hosta
podczas przypisania do urządzenia zapośredniczonego (mdev).

Problem 1:
~~~~~~~~~
AP_RESPONSE_Q_NOT_AVAIL nie jest obsługiwane w vfio_ap_mdev_reset_queue()

Gdy magistrala AP usuwa urządzenie z kolejki, którego adapter lub domena ma
został usunięty z konfiguracji AP hosta,
Wywoływana jest funkcja vfio_ap_mdev_remove_queue(). Jeśli kolejka nadal jest w
konfigurację AP hosta w tym momencie, wywołuje
vfio_ap_mdev_reset_queue(), która wystawia PQAP(ZAPQ). Od
adapter zniknął już z konfiguracji hosta, funkcja ap_zapq() powraca
AP_RESPONSE_Q_NOT_AVAIL (0x01). Ten kod odpowiedzi nie jest obsługiwany
instrukcję switch vfio_ap_mdev_reset_queue() i przechodzi do
przypadek domyślny, który generuje WARN, ale nie wywołuje
vfio_ap_free_aqic_resources(). W rezultacie, jeśli obsługa przerwań była
włączone dla kolejki przez gościa, rejestracja KVM GISC i
przypięta strona gościa zawierająca bajt wskaźnika powiadomienia (NIB)
oba wyciekły.

Zostało to naprawione poprzez dodanie AP_RESPONSE_Q_NOT_AVAIL do tego samego przypadku co
AP_RESPONSE_DECONFIGURED i AP_RESPONSE_CHECKSTOPPED w
vfio_ap_mdev_reset_queue(). Podobnie jak te kody odpowiedzi, Q_NOT_AVAIL
wskazuje, że kolejka nie działa i nie ma dalszych prób resetowania
są możliwe; właściwym działaniem jest zwolnienie zasobów IRQ
natychmiast.

Problem 2:
~~~~~~~~~
AP_RESPONSE_Q_NOT_AVAIL nie jest obsługiwane w apq_status_check()

W funkcji vfio_ap_mdev_reset_queue() istnieją cztery przypadki wskazujące kolejkę
reset nie został jeszcze zakończony, w takim przypadku funkcja apq_reset_check() znajduje się w kolejce
kolejka robocza w celu sprawdzenia zakończenia operacji resetowania. Ta funkcja
używa funkcji PQAP(TAPQ) w celu uzyskania statusu kolejki i wywołań
apq_status_check(), aby sprawdzić, czy resetowanie zostało zakończone, nie powiodło się lub
należy wykonać ponownie. Jak opisano w zadaniu nr 1 powyżej,
apq_reset_check() nie sprawdza konkretnie AP_RESPONSE_Q_NOT_AVAIL,
potencjalnie wyciekając w ten sposób rejestracja KVM GISC i przypięta strona gościa
trzymając NIB.

Zostało to naprawione poprzez dodanie instrukcji case dla AP_RESPONSE_Q_NOT_AVAIL do
apq_status_check() i zwrócenie -ENODEV w tym przypadku. Osoba dzwoniąca,
apq_reset_check() następnie sprawdzi ten kod powrotu i wywoła
vfio_ap_free_aqic_resources(), aby zapobiec wyciekowi.

Problem 3:
~~~~~~~~~
vfio_ap_free_aqic_resources() wycieka zapisany_isc, gdy kvm ma wartość NULL

vfio_ap_free_aqic_resources() chroni wywołanie
kvm_s390_gisc_unregister() z:

if (q->saved_isc != VFIO_AP_ISC_INVALID &&
!WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))

Jeśli matrix_mdev->kvm ma wartość NULL - co może się zdarzyć, gdy
vfio_ap_mdev_unset_kvm() została już uruchomiona i wyczyściła kvm przed
kolejna ścieżka czyszczenia osiąga tę funkcję - uruchamia się WARN_ON
i cały blok zostaje pominięty. To pozostawia q->saved_isc ustawione na a
nieprawidłowa wartość, tworząca potencjalne podwójne zwolnienie przy każdej kolejnej
wywołać tę funkcję.

Kiedy kvm ma wartość NULL, gość KVM jest już wyłączony, więc
kvm_s390_gisc_unregister() nie musi i nie może zostać wywołana; jednakże,
q->saved_isc musi być zawsze wyczyszczone. Napraw to, oddzielając plik
kvm_s390_gisc_unregister() z resetu q->saved_isc. The
WARN_ON chroni teraz tylko naprawdę niemożliwy przypadek matrix_mdev
będąc NULL. NULL kvm jest obsługiwany z wdziękiem poprzez pominięcie tylko
wyrejestruj połączenie i ustawiono q->saved_isc = VFIO_AP_ISC_INVALID
bezwarunkowo, ilekroć zapisany_isc nie był już nieprawidłowy.

Dodatkowo dodaj klauzulę else do odprawy host-config
vfio_ap_mdev_remove_queue(), aby wywołać vfio_ap_free_aqic_resources()
bezpośrednio, gdy kolejka nie znajduje się w konfiguracji AP hosta. To
służy jako zabezpieczenie: gdy magistrala AP odpala sterownik .remove
wywołanie zwrotne po usunięciu adaptera z konfiguracji hosta, kolejki
z definicji nie jest już adresowalny, więc vfio_ap_mdev_reset_queue
---obcięty---

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

s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config

Three related problems exist in the handling of KVM interrupt and page
resources when a queue is removed from the host's AP configuration
while assigned to a mediated device (mdev).

Problem 1:
~~~~~~~~~
AP_RESPONSE_Q_NOT_AVAIL not handled in vfio_ap_mdev_reset_queue()

When the AP bus removes a queue device whose adapter or domain has
been removed from the host's AP configuration,
vfio_ap_mdev_remove_queue() is called. If the queue is still in the
host's AP configuration at that point, it calls
vfio_ap_mdev_reset_queue(), which issues a PQAP(ZAPQ). Since the
adapter is already gone from the host configuration, ap_zapq() returns
AP_RESPONSE_Q_NOT_AVAIL (0x01). This response code is not handled in
vfio_ap_mdev_reset_queue()'s switch statement and falls through to
the default case, which issues a WARN but does not call
vfio_ap_free_aqic_resources(). As a result, if IRQ handling was
enabled for the queue by the guest, the KVM GISC registration and
the pinned guest page holding the notification indicator byte (NIB)
are both leaked.

This is fixed by adding AP_RESPONSE_Q_NOT_AVAIL to the same case as
AP_RESPONSE_DECONFIGURED and AP_RESPONSE_CHECKSTOPPED in
vfio_ap_mdev_reset_queue(). Like those response codes, Q_NOT_AVAIL
indicates the queue is not operational and no further reset attempts
are possible; the correct action is to free the IRQ resources
immediately.

Problem 2:
~~~~~~~~~
AP_RESPONSE_Q_NOT_AVAIL not handled in apq_status_check()

In vfio_ap_mdev_reset_queue(), there are four cases that indicate a queue
reset has not yet completed, in which case apq_reset_check() is queued to
a work queue to verify completion of the reset operation. This function
uses the PQAP(TAPQ) function to get the queue's status and calls
apq_status_check() to verify whether the reset has completed, failed or
needs to be executed again. As described in Problem #1 above,
apq_reset_check() does not specifically check for AP_RESPONSE_Q_NOT_AVAIL,
thereby potentially leaking KVM GISC registration and the pinned guest page
holding the NIB.

This is fixed by adding a case statement for AP_RESPONSE_Q_NOT_AVAIL to
apq_status_check() and returning -ENODEV for that case. The caller,
apq_reset_check() will then check for this return code and call
vfio_ap_free_aqic_resources() to prevent the leak.

Problem 3:
~~~~~~~~~
vfio_ap_free_aqic_resources() leaks saved_isc when kvm is NULL

vfio_ap_free_aqic_resources() guards the call to
kvm_s390_gisc_unregister() with:

if (q->saved_isc != VFIO_AP_ISC_INVALID &&
!WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))

If matrix_mdev->kvm is NULL -- which can happen when
vfio_ap_mdev_unset_kvm() has already run and cleared kvm before a
subsequent cleanup path reaches this function -- the WARN_ON fires
and the entire block is skipped. This leaves q->saved_isc set to a
non-invalid value, creating a potential double-free on any subsequent
call to this function.

When kvm is NULL the KVM guest is already torn down, so
kvm_s390_gisc_unregister() need not and cannot be called; however,
q->saved_isc must always be cleared. Fix this by separating the
kvm_s390_gisc_unregister() call from the q->saved_isc reset. The
WARN_ON now guards only the genuinely impossible case of matrix_mdev
being NULL. A NULL kvm is handled gracefully by skipping only the
unregister call, and q->saved_isc = VFIO_AP_ISC_INVALID is set
unconditionally whenever saved_isc was not already invalid.

Additionally, add an else clause to the host-config check in
vfio_ap_mdev_remove_queue() to call vfio_ap_free_aqic_resources()
directly when the queue is not in the host's AP configuration. This
serves as a backstop: when the AP bus fires the driver .remove
callback after an adapter is removed from the host config, the queue
is by definition no longer addressable, so vfio_ap_mdev_reset_queue
---truncated---

>_ 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