{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-98473 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-98473 is a memory corruption vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-98473 and fix it if it is affected.\n\nWhat it is: CVE-2026-98473 is a memory corruption vulnerability in Linux, published on 18 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-98473 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-98473/ (Markdown: https://insights.sbomify.com/CVE-2026-98473/index.md)","id":"CVE-2026-98473","markdown":"https://insights.sbomify.com/CVE-2026-98473/index.md","name":"CVE-2026-98473","record":{"aliases":["AZL-109431","BELL-CVE-2026-98473","DEBIAN-CVE-2026-98473","GHSA-67g9-vc6v-4v6c","UBUNTU-CVE-2026-98473"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service","data_read"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel","requires_auth":"high_privilege","summary":"A local attacker with high privileges can trigger a memory leak in the Linux kernel's s390/vfio-ap driver, potentially leading to denial of service or information disclosure.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"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's 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'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.\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'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.\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'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---","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"s390/vfio-ap: fix KVM GISC and page leak when queue removed from host config","id":"CVE-2026-98473","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":4,"next":{"headline":"s390/pci: Fix missing device lock in zpci_report_status()","id":"CVE-2026-98474"},"packages":[],"prev":{"headline":"KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV","id":"CVE-2026-98472"},"products":["Linux"],"published":"2026-10-18","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-10-19","vendors":["Linux"]},"summary":"A local attacker with high privileges can trigger a memory leak in the Linux kernel's s390/vfio-ap driver, potentially leading to denial of service or information disclosure.","url":"https://insights.sbomify.com/CVE-2026-98473/"}