{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-26939 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-26939 is a high-severity use after free vulnerability in Linux kernel, 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-26939 and fix it if it is affected.\n\nWhat it is: CVE-2024-26939 is a high-severity use after free vulnerability in Linux kernel, 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-26939 in the wild and no public exploit code.\n\nAffected product: Linux kernel. 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-26939/ (Markdown: https://insights.sbomify.com/CVE-2024-26939/index.md)","id":"CVE-2024-26939","markdown":"https://insights.sbomify.com/CVE-2024-26939/index.md","name":"CVE-2024-26939","record":{"aliases":["BELL-CVE-2024-26939","DEBIAN-CVE-2024-26939","GHSA-gghh-gpx3-pmx6","UBUNTU-CVE-2024-26939"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","privilege_escalation"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel driver","requires_auth":"low_privilege","summary":"A race condition in the Intel i915 GPU driver allows a use-after-free, potentially enabling local attackers to execute code or escalate privileges.","user_interaction":"not_required","vuln_class":"use_after_free"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"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-416","name":"Use After Free"}],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/vma: Fix UAF on destroy against retire race\n\nObject debugging tools were sporadically reporting illegal attempts to\nfree a still active i915 VMA object when parking a GT believed to be idle.\n\n[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]\n[161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0\n...\n[161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1\n[161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022\n[161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]\n[161.360592] RIP: 0010:debug_print_object+0x80/0xb0\n...\n[161.361347] debug_object_free+0xeb/0x110\n[161.361362] i915_active_fini+0x14/0x130 [i915]\n[161.361866] release_references+0xfe/0x1f0 [i915]\n[161.362543] i915_vma_parked+0x1db/0x380 [i915]\n[161.363129] __gt_park+0x121/0x230 [i915]\n[161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]\n\nThat has been tracked down to be happening when another thread is\ndeactivating the VMA inside __active_retire() helper, after the VMA's\nactive counter has been already decremented to 0, but before deactivation\nof the VMA's object is reported to the object debugging tool.\n\nWe could prevent from that race by serializing i915_active_fini() with\n__active_retire() via ref-\u003etree_lock, but that wouldn't stop the VMA from\nbeing used, e.g. from __i915_vma_retire() called at the end of\n__active_retire(), after that VMA has been already freed by a concurrent\ni915_vma_destroy() on return from the i915_active_fini().  Then, we should\nrather fix the issue at the VMA level, not in i915_active.\n\nSince __i915_vma_parked() is called from __gt_park() on last put of the\nGT's wakeref, the issue could be addressed by holding the GT wakeref long\nenough for __active_retire() to complete before that wakeref is released\nand the GT parked.\n\nI believe the issue was introduced by commit d93939730347 (\"drm/i915:\nRemove the vma refcount\") which moved a call to i915_active_fini() from\na dropped i915_vma_release(), called on last put of the removed VMA kref,\nto i915_vma_parked() processing path called on last put of a GT wakeref.\nHowever, its visibility to the object debugging tool was suppressed by a\nbug in i915_active that was fixed two weeks later with commit e92eb246feb9\n(\"drm/i915/active: Fix missing debug object activation\").\n\nA VMA associated with a request doesn't acquire a GT wakeref by itself.\nInstead, it depends on a wakeref held directly by the request's active\nintel_context for a GT associated with its VM, and indirectly on that\nintel_context's engine wakeref if the engine belongs to the same GT as the\nVMA's VM.  Those wakerefs are released asynchronously to VMA deactivation.\n\nFix the issue by getting a wakeref for the VMA's GT when activating it,\nand putting that wakeref only after the VMA is deactivated.  However,\nexclude global GTT from that processing path, otherwise the GPU never goes\nidle.  Since __i915_vma_retire() may be called from atomic contexts, use\nasync variant of wakeref put.  Also, to avoid circular locking dependency,\ntake care of acquiring the wakeref before VM mutex when both are needed.\n\nv7: Add inline comments with justifications for:\n    - using untracked variants of intel_gt_pm_get/put() (Nirmoy),\n    - using async variant of _put(),\n    - not getting the wakeref in case of a global GTT,\n    - always getting the first wakeref outside vm-\u003emutex.\nv6: Since __i915_vma_active/retire() callbacks are not serialized, storing\n    a wakeref tracking handle inside struct i915_vma is not safe, and\n    there is no other good place for that.  Use untracked variants of\n    intel_gt_pm_get/put_async().\nv5: Replace \"tile\" with \"GT\" across commit description (Rodrigo),\n  - \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":"drm/i915/vma: Fix UAF on destroy against retire race","id":"CVE-2024-26939","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"use_after_free","year":"2024"},"n_packages":0,"n_references":4,"next":{"headline":"drm/vmwgfx: Create debugfs ttm_resource_manager entry only if needed","id":"CVE-2024-26940"},"packages":[],"prev":{"headline":"drm/i915/bios: Tolerate devdata==NULL in intel_bios_encoder_supports_dp_dual_mode()","id":"CVE-2024-26938"},"products":["Linux"],"published":"2024-05-01","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"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 the Intel i915 GPU driver allows a use-after-free, potentially enabling local attackers to execute code or escalate privileges.","url":"https://insights.sbomify.com/CVE-2024-26939/"}