{"answers":{"affected":"It affects 2 products.","exploited":"There is no known exploitation of CVE-2024-26976 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-26976 is a high-severity vulnerability in Debian Debian Linux, published on 1 May 2024. 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-2024-26976 and fix it if it is affected.\n\nWhat it is: CVE-2024-26976 is a high-severity vulnerability in Debian Debian Linux, published on 1 May 2024. 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-2024-26976 in the wild and no public exploit code.\n\nAffected product: Debian Debian 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-2024-26976/ (Markdown: https://insights.sbomify.com/CVE-2024-26976/index.md)","id":"CVE-2024-26976","markdown":"https://insights.sbomify.com/CVE-2024-26976/index.md","name":"CVE-2024-26976","record":{"aliases":["BELL-CVE-2024-26976","DEBIAN-CVE-2024-26976","GHSA-qc4m-rx2p-hrfv","UBUNTU-CVE-2024-26976"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel KVM","requires_auth":"low_privilege","summary":"A race condition in KVM's async page fault handling can cause a deadlock and system hang when destroying a virtual CPU.","user_interaction":"not_required","vuln_class":"race_condition"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"debian_linux","vendor":"debian"},{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[{"id":"CWE-400","name":"Uncontrolled Resource Consumption"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\n\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put.  Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\n\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock.  async_pf_execute() can't return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:\n\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n  \u003cTASK\u003e\n  async_pf_execute+0x198/0x260 [kvm]\n  process_one_work+0x145/0x2d0\n  worker_thread+0x27e/0x3a0\n  kthread+0xba/0xe0\n  ret_from_fork+0x2d/0x50\n  ret_from_fork_asm+0x11/0x20\n  \u003c/TASK\u003e\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n       Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n  \u003cTASK\u003e\n  __schedule+0x33f/0xa40\n  schedule+0x53/0xc0\n  schedule_timeout+0x12a/0x140\n  __wait_for_common+0x8d/0x1d0\n  __flush_work.isra.0+0x19f/0x2c0\n  kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n  kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n  kvm_put_kvm+0x1c1/0x320 [kvm]\n  async_pf_execute+0x198/0x260 [kvm]\n  process_one_work+0x145/0x2d0\n  worker_thread+0x27e/0x3a0\n  kthread+0xba/0xe0\n  ret_from_fork+0x2d/0x50\n  ret_from_fork_asm+0x11/0x20\n  \u003c/TASK\u003e\n\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there's no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed.  And that in turn fixes the module\nunloading bug as __fput() won't do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\n\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue().  Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that's a very, very small chance, and likely a very\nsmall delay.  kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\n\n        trace_kvm_async_pf_completed(addr, cr2_or_gpa);\n\n        __kvm_vcpu_wake_up(vcpu);\n\n        mmput(mm);\n\nand mmput() can't drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won't get stuck tearing down page tables.\n\nAdd a helper to do the flushing, specifically to deal with \"wakeup all\"\nwork items, as they aren't actually work items, i.e. are never placed in a\nworkqueue.  Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\n\nNote, commit 5f6de5cbebee (\"KVM: Prevent module exit until al\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":"KVM: Always flush async #PF workqueue when vCPU is being destroyed","id":"CVE-2024-26976","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"debian:debian_linux","products":["debian:debian_linux","linux:linux_kernel"],"type":"race_condition","year":"2024"},"n_packages":0,"n_references":9,"next":{"headline":"pci_iounmap(): Fix MMIO mapping leak","id":"CVE-2024-26977"},"packages":[],"prev":{"headline":"powercap: intel_rapl: Fix a NULL pointer dereference","id":"CVE-2024-26975"},"products":["Linux"],"published":"2024-05-01","related":[{"cvss_score":10,"headline":"ProFTPD Improper Access Control","id":"CVE-2015-3306","kev_date_added":"2026-10-08","published":"2015-05-18"},{"cvss_score":9.9,"headline":"RoundCube Webmail Deserialization of Untrusted Data","id":"CVE-2025-49113","kev_date_added":"2026-02-20","published":"2025-06-02"},{"cvss_score":9.8,"headline":"GNU InetUtils Argument Injection","id":"CVE-2026-24061","kev_date_added":"2026-01-26","published":"2026-01-21"},{"cvss_score":9.8,"headline":"Linux Kernel Improper Check for Unusual or Exceptional Conditions","id":"CVE-2025-39682","kev_date_added":"2026-09-18","published":"2025-09-05"},{"cvss_score":9.8,"headline":"Mozilla Firefox Use-After-Free","id":"CVE-2024-9680","kev_date_added":"2024-10-15","published":"2024-10-09"},{"cvss_score":9.8,"headline":"RARLAB UnRAR Directory Traversal","id":"CVE-2022-30333","kev_date_added":"2022-08-09","published":"2022-05-09"},{"cvss_score":9.8,"headline":"Roundcube Webmail SQL Injection","id":"CVE-2021-44026","kev_date_added":"2023-06-22","published":"2021-11-19"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"total"},"state":"PUBLISHED","updated":"2026-08-05","vendors":["Linux"]},"summary":"A race condition in KVM's async page fault handling can cause a deadlock and system hang when destroying a virtual CPU.","url":"https://insights.sbomify.com/CVE-2024-26976/"}