FKIE_CVE-2026-98473

Vulnerability from fkie_nvd - Published: 2026-10-18 16:16 - Updated: 2026-10-19 10:18
Severity
Summary
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---
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3c3433657c82f200dae36c29e2b80681c81b85be
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/65e05ec252a9b79e75930d3c4dd42d8877db04c5
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/cf441a0db681dfad5e89b015d6be11365159d7a9
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/da69d3ac53490724eba0ade9deb4e539a6ae9034
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/s390/crypto/vfio_ap_ops.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "da69d3ac53490724eba0ade9deb4e539a6ae9034",
              "status": "affected",
              "version": "b9bd10c43456d16abd97b717446f51afb3b88411",
              "versionType": "git"
            },
            {
              "lessThan": "cf441a0db681dfad5e89b015d6be11365159d7a9",
              "status": "affected",
              "version": "b9bd10c43456d16abd97b717446f51afb3b88411",
              "versionType": "git"
            },
            {
              "lessThan": "3c3433657c82f200dae36c29e2b80681c81b85be",
              "status": "affected",
              "version": "b9bd10c43456d16abd97b717446f51afb3b88411",
              "versionType": "git"
            },
            {
              "lessThan": "65e05ec252a9b79e75930d3c4dd42d8877db04c5",
              "status": "affected",
              "version": "b9bd10c43456d16abd97b717446f51afb3b88411",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "582014b08cb83383cdd61f052cd81e8aa5023696",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "7abe1494896c052d5dcf4ba910656777aff72fbb",
              "versionType": "git"
            },
            {
              "lessThan": "6.7",
              "status": "affected",
              "version": "6.6.15",
              "versionType": "semver"
            },
            {
              "lessThan": "6.8",
              "status": "affected",
              "version": "6.7.3",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/s390/crypto/vfio_ap_ops.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.8"
            },
            {
              "lessThan": "6.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.112",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.55",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.2.*",
              "status": "unaffected",
              "version": "7.2.9",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/vfio-ap: fix KVM GISC and page leak when queue removed from host config\n\nThree related problems exist in the handling of KVM interrupt and page\nresources when a queue is removed from the host\u0027s AP configuration\nwhile assigned to a mediated device (mdev).\n\nProblem 1:\n~~~~~~~~~\nAP_RESPONSE_Q_NOT_AVAIL not handled in vfio_ap_mdev_reset_queue()\n\nWhen the AP bus removes a queue device whose adapter or domain has\nbeen removed from the host\u0027s AP configuration,\nvfio_ap_mdev_remove_queue() is called. If the queue is still in the\nhost\u0027s 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()\u0027s 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.\n\nThis 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.\n\nProblem 2:\n~~~~~~~~~\n AP_RESPONSE_Q_NOT_AVAIL not handled in apq_status_check()\n\nIn 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\u0027s 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.\n\nThis 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.\n\nProblem 3:\n~~~~~~~~~\nvfio_ap_free_aqic_resources() leaks saved_isc when kvm is NULL\n\nvfio_ap_free_aqic_resources() guards the call to\nkvm_s390_gisc_unregister() with:\n\n    if (q-\u003esaved_isc != VFIO_AP_ISC_INVALID \u0026\u0026\n        !WARN_ON(!(q-\u003ematrix_mdev \u0026\u0026 q-\u003ematrix_mdev-\u003ekvm)))\n\nIf matrix_mdev-\u003ekvm 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-\u003esaved_isc set to a\nnon-invalid value, creating a potential double-free on any subsequent\ncall to this function.\n\nWhen kvm is NULL the KVM guest is already torn down, so\nkvm_s390_gisc_unregister() need not and cannot be called; however,\nq-\u003esaved_isc must always be cleared. Fix this by separating the\nkvm_s390_gisc_unregister() call from the q-\u003esaved_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-\u003esaved_isc = VFIO_AP_ISC_INVALID is set\nunconditionally whenever saved_isc was not already invalid.\n\nAdditionally, 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\u0027s 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---"
    }
  ],
  "id": "CVE-2026-98473",
  "lastModified": "2026-10-19T10:18:57.850",
  "metrics": {},
  "published": "2026-10-18T16:16:57.793",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3c3433657c82f200dae36c29e2b80681c81b85be"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/65e05ec252a9b79e75930d3c4dd42d8877db04c5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/cf441a0db681dfad5e89b015d6be11365159d7a9"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/da69d3ac53490724eba0ade9deb4e539a6ae9034"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Received"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.