In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
s390\/vfio-ap: fix KVM GISC and page leak when queue removed from host config<\/p>\n
Three related problems exist in the handling of KVM interrupt and page
\nresources when a queue is removed from the host’s AP configuration
\nwhile assigned to a mediated device (mdev).<\/p>\n
Problem 1:
\n~~~~~~~~~
\nAP_RESPONSE_Q_NOT_AVAIL not handled in vfio_ap_mdev_reset_queue()<\/p>\n
When the AP bus removes a queue device whose adapter or domain has
\nbeen removed from the host’s AP configuration,
\nvfio_ap_mdev_remove_queue() is called. If the queue is still in the
\nhost’s AP configuration at that point, it calls
\nvfio_ap_mdev_reset_queue(), which issues a PQAP(ZAPQ). Since the
\nadapter is already gone from the host configuration, ap_zapq() returns
\nAP_RESPONSE_Q_NOT_AVAIL (0x01). This response code is not handled in
\nvfio_ap_mdev_reset_queue()’s switch statement and falls through to
\nthe default case, which issues a WARN but does not call
\nvfio_ap_free_aqic_resources(). As a result, if IRQ handling was
\nenabled for the queue by the guest, the KVM GISC registration and
\nthe pinned guest page holding the notification indicator byte (NIB)
\nare both leaked.<\/p>\n
This is fixed by adding AP_RESPONSE_Q_NOT_AVAIL to the same case as
\nAP_RESPONSE_DECONFIGURED and AP_RESPONSE_CHECKSTOPPED in
\nvfio_ap_mdev_reset_queue(). Like those response codes, Q_NOT_AVAIL
\nindicates the queue is not operational and no further reset attempts
\nare possible; the correct action is to free the IRQ resources
\nimmediately.<\/p>\n
Problem 2:
\n~~~~~~~~~
\n AP_RESPONSE_Q_NOT_AVAIL not handled in apq_status_check()<\/p>\n
In vfio_ap_mdev_reset_queue(), there are four cases that indicate a queue
\nreset has not yet completed, in which case apq_reset_check() is queued to
\na work queue to verify completion of the reset operation. This function
\nuses the PQAP(TAPQ) function to get the queue’s status and calls
\napq_status_check() to verify whether the reset has completed, failed or
\nneeds to be executed again. As described in Problem #1 above,
\napq_reset_check() does not specifically check for AP_RESPONSE_Q_NOT_AVAIL,
\nthereby potentially leaking KVM GISC registration and the pinned guest page
\nholding the NIB.<\/p>\n
This is fixed by adding a case statement for AP_RESPONSE_Q_NOT_AVAIL to
\napq_status_check() and returning -ENODEV for that case. The caller,
\napq_reset_check() will then check for this return code and call
\nvfio_ap_free_aqic_resources() to prevent the leak.<\/p>\n
Problem 3:
\n~~~~~~~~~
\nvfio_ap_free_aqic_resources() leaks saved_isc when kvm is NULL<\/p>\n
vfio_ap_free_aqic_resources() guards the call to
\nkvm_s390_gisc_unregister() with:<\/p>\n
if (q->saved_isc != VFIO_AP_ISC_INVALID &&
\n !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm)))<\/p>\n
If matrix_mdev->kvm is NULL — which can happen when
\nvfio_ap_mdev_unset_kvm() has already run and cleared kvm before a
\nsubsequent cleanup path reaches this function — the WARN_ON fires
\nand the entire block is skipped. This leaves q->saved_isc set to a
\nnon-invalid value, creating a potential double-free on any subsequent
\ncall to this function.<\/p>\n
When kvm is NULL the KVM guest is already torn down, so
\nkvm_s390_gisc_unregister() need not and cannot be called; however,
\nq->saved_isc must always be cleared. Fix this by separating the
\nkvm_s390_gisc_unregister() call from the q->saved_isc reset. The
\nWARN_ON now guards only the genuinely impossible case of matrix_mdev
\nbeing NULL. A NULL kvm is handled gracefully by skipping only the
\nunregister call, and q->saved_isc = VFIO_AP_ISC_INVALID is set
\nunconditionally whenever saved_isc was not already invalid.<\/p>\n
Additionally, add an else clause to the host-config check in
\nvfio_ap_mdev_remove_queue() to call vfio_ap_free_aqic_resources()
\ndirectly when the queue is not in the host’s AP configuration. This
\nserves as a backstop: when the AP bus fires the driver .remove
\ncallback after an adapter is removed from the host config, the queue
\nis by definition no longer addressable, so vfio_ap_mdev_reset_queue
\n—truncated—<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
s390\/vfio-ap: fix KVM GISC and page leak when queue removed from host config<\/p>\n
Three related problems exist in the handling of KVM i<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-40945","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/40945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=40945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=40945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=40945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}