{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-26939", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-02-19T14:20:24.196Z", "datePublished": "2024-05-01T05:17:44.370Z", "dateUpdated": "2024-11-05T09:18:33.738Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:18:33.738Z"}, "descriptions": [{"lang": "en", "value": "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->tree_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->mutex.\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---"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/gpu/drm/i915/i915_vma.c"], "versions": [{"version": "d93939730347", "lessThan": "704edc9252f4", "status": "affected", "versionType": "git"}, {"version": "d93939730347", "lessThan": "5e3eb862df9f", "status": "affected", "versionType": "git"}, {"version": "d93939730347", "lessThan": "59b2626dd8c8", "status": "affected", "versionType": "git"}, {"version": "d93939730347", "lessThan": "0e45882ca829", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/gpu/drm/i915/i915_vma.c"], "versions": [{"version": "5.19", "status": "affected"}, {"version": "0", "lessThan": "5.19", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.88", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.29", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.8.3", "lessThanOrEqual": "6.8.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.9", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190"}, {"url": "https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5"}, {"url": "https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f"}, {"url": "https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e"}], "title": "drm/i915/vma: Fix UAF on destroy against retire race", "x_generator": {"engine": "bippy-9e1c9544281a"}}, "adp": [{"problemTypes": [{"descriptions": [{"type": "CWE", "cweId": "CWE-416", "lang": "en", "description": "CWE-416 Use After Free"}]}], "metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2024-06-06T18:59:58.125327Z", "id": "CVE-2024-26939", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "total"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-06T19:00:13.886Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T00:21:05.670Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e", "tags": ["x_transferred"]}]}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e", "tags": ["x_transferred"]}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T00:21:05.670Z"}}, {"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-26939", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "total"}], "version": "2.0.3", "timestamp": "2024-06-06T18:59:58.125327Z"}}}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-416", "description": "CWE-416 Use After Free"}]}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-06T19:00:10.532Z"}}], "cna": {"title": "drm/i915/vma: Fix UAF on destroy against retire race", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "d93939730347", "lessThan": "704edc9252f4", "versionType": "git"}, {"status": "affected", "version": "d93939730347", "lessThan": "5e3eb862df9f", "versionType": "git"}, {"status": "affected", "version": "d93939730347", "lessThan": "59b2626dd8c8", "versionType": "git"}, {"status": "affected", "version": "d93939730347", "lessThan": "0e45882ca829", "versionType": "git"}], "programFiles": ["drivers/gpu/drm/i915/i915_vma.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.19"}, {"status": "unaffected", "version": "0", "lessThan": "5.19", "versionType": "semver"}, {"status": "unaffected", "version": "6.1.88", "versionType": "semver", "lessThanOrEqual": "6.1.*"}, {"status": "unaffected", "version": "6.6.29", "versionType": "semver", "lessThanOrEqual": "6.6.*"}, {"status": "unaffected", "version": "6.8.3", "versionType": "semver", "lessThanOrEqual": "6.8.*"}, {"status": "unaffected", "version": "6.9", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["drivers/gpu/drm/i915/i915_vma.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190"}, {"url": "https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5"}, {"url": "https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f"}, {"url": "https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e"}], "x_generator": {"engine": "bippy-9e1c9544281a"}, "descriptions": [{"lang": "en", "value": "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->tree_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->mutex.\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---"}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-05T09:18:33.738Z"}}}, "cveMetadata": {"cveId": "CVE-2024-26939", "state": "PUBLISHED", "dateUpdated": "2024-11-05T09:18:33.738Z", "dateReserved": "2024-02-19T14:20:24.196Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-05-01T05:17:44.370Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "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->tree_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->mutex.\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---"}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: drm/i915/vma: Correcci\u00f3n de UAF al destruir contra ejecuci\u00f3n de retirada. Las herramientas de depuraci\u00f3n de objetos informaban espor\u00e1dicamente intentos ilegales de liberar un objeto i915 VMA a\u00fan activo al estacionar un GT que se cre\u00eda que estaba inactivo. [161.359441] ODEBUG: objeto activo libre (estado activo 0): ffff88811643b958 tipo de objeto: i915_active sugerencia: __i915_vma_active+0x0/0x50 [i915] [161.360082] ADVERTENCIA: CPU: 5 PID: 276 en lib/debugobjects.c:514 _imprimir_objeto+ 0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 No contaminado 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Nombre de hardware: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 21/04/2022 [161.360322] Cola de trabajo: i915 desordenado __intel_wakeref_put_work [i915] [161.360592] RIP 0010:debug_print_object+0x 80/0xb0... [161.361347] debug_object_free +0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] referencias de versi\u00f3n+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] .363129] __gt_park+0x121/0x230 [i915] [161.363515 ] ____intel_wakeref_put_last+0x1f/0x70 [i915] Se ha rastreado que eso sucede cuando otro subproceso desactiva el VMA dentro del asistente __active_retire(), despu\u00e9s de que el contador activo del VMA ya se haya reducido a 0, pero antes de que se desactive la desactivaci\u00f3n del objeto del VMA. reportado a la herramienta de depuraci\u00f3n de objetos. Podr\u00edamos evitar esa ejecuci\u00f3n serializando i915_active_fini() con __active_retire() a trav\u00e9s de ref->tree_lock, pero eso no impedir\u00eda que se use VMA, por ejemplo, desde __i915_vma_retire() llamado al final de __active_retire(), despu\u00e9s de ese VMA ya ha sido liberado por un i915_vma_destroy() concurrente al regresar de i915_active_fini(). Entonces, deber\u00edamos solucionar el problema a nivel de VMA, no en i915_active. Dado que __i915_vma_parked() se llama desde __gt_park() en la \u00faltima colocaci\u00f3n del wakeref del GT, el problema podr\u00eda solucionarse manteniendo el wakeref del GT el tiempo suficiente para que __active_retire() se complete antes de que se libere el wakeref y se estacione el GT. Creo que el problema fue introducido por el commit d93939730347 (\"drm/i915: Eliminar el recuento de vma\") que movi\u00f3 una llamada a i915_active_fini() desde un i915_vma_release() eliminado, llamado en la \u00faltima colocaci\u00f3n del kref de VMA eliminado, a i915_vma_parked() ruta de procesamiento llamada en la \u00faltima colocaci\u00f3n de un wakeref GT. Sin embargo, su visibilidad para la herramienta de depuraci\u00f3n de objetos fue suprimida por un error en i915_active que se solucion\u00f3 dos semanas despu\u00e9s con el commit e92eb246feb9 (\"drm/i915/active: Reparar la activaci\u00f3n del objeto de depuraci\u00f3n que falta\"). Un VMA asociado con una solicitud no adquiere un wakeref GT por s\u00ed solo. En cambio, depende de un wakeref mantenido directamente por el intel_context activo de la solicitud para un GT asociado con su VM, e indirectamente del wakeref del motor de ese intel_context si el motor pertenece al mismo GT que la VM del VMA. Esos wakerefs se liberan de forma asincr\u00f3nica con la desactivaci\u00f3n de VMA. Solucione el problema obteniendo un wakeref para el GT del VMA al activarlo y colocando ese wakeref solo despu\u00e9s de que se desactive el VMA. Sin embargo, excluya el GTT global de esa ruta de procesamiento; de lo contrario, la GPU nunca quedar\u00e1 inactiva. Dado que se puede llamar a __i915_vma_retire() desde contextos at\u00f3micos, utilice la variante as\u00edncrona de wakeref put. Adem\u00e1s, para evitar la dependencia del bloqueo circular, tenga cuidado de adquirir el wakeref antes del mutex de VM cuando ambos sean necesarios. v7: agregue comentarios en l\u00ednea con justificaciones para: - usar variantes sin seguimiento de intel_gt_pm_get/put() (Nirmoy), - usar la variante as\u00edncrona de _put(), - no obtener el wakeref en caso de un GTT global, - obtener siempre el primer wakeref fuera de vm->mutex. ---truncado---"}], "id": "CVE-2024-26939", "lastModified": "2024-07-03T01:50:03.663", "metrics": {}, "published": "2024-05-01T06:15:09.193", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/0e45882ca829b26b915162e8e86dbb1095768e9e"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/59b2626dd8c8a2e13f18054b3530e0c00073d79f"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/704edc9252f4988ae1ad7dafa23d0db8d90d7190"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-416"}], "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "type": "Secondary"}]}

{"affected_release": [{"advisory": "RHSA-2024:7001", "cpe": "cpe:/a:redhat:enterprise_linux:8::nfv", "package": "kernel-rt-0:4.18.0-553.22.1.rt7.363.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-09-24T00:00:00Z"}, {"advisory": "RHSA-2024:7000", "cpe": "cpe:/o:redhat:enterprise_linux:8", "package": "kernel-0:4.18.0-553.22.1.el8_10", "product_name": "Red Hat Enterprise Linux 8", "release_date": "2024-09-24T00:00:00Z"}, {"advisory": "RHSA-2024:9315", "cpe": "cpe:/a:redhat:enterprise_linux:9", "package": "kernel-0:5.14.0-503.11.1.el9_5", "product_name": "Red Hat Enterprise Linux 9", "release_date": "2024-11-12T00:00:00Z"}, {"advisory": "RHSA-2024:9315", "cpe": "cpe:/o:redhat:enterprise_linux:9", "package": "kernel-0:5.14.0-503.11.1.el9_5", "product_name": "Red Hat Enterprise Linux 9", "release_date": "2024-11-12T00:00:00Z"}], "bugzilla": {"description": "kernel: drm/i915/vma: Fix UAF on destroy against retire race", "id": "2278220", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2278220"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "verified"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\ndrm/i915/vma: Fix UAF on destroy against retire race\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[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]\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.\nWe could prevent from that race by serializing i915_active_fini() with\n__active_retire() via ref->tree_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.\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.\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\").\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.\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.\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->mutex.\nv6: Since __i915_vma_active/retire() callbacks are not serialized, storing\na wakeref tracking handle inside struct i915_vma is not safe, and\nthere is no other good place for that. Use untracked variants of\nintel_gt_pm_get/put_async().\nv5: Replace \"tile\" with \"GT\" across commit description (Rodrigo),\n- \n---truncated---", "A use-after-free flaw was found in drivers/gpu/drm/i915/i915_vma.c in the Linux kernel that may lead to a crash."], "name": "CVE-2024-26939", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-05-01T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-26939\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-26939\nhttps://lore.kernel.org/linux-cve-announce/2024050124-CVE-2024-26939-5314@gregkh/T"], "threat_severity": "Moderate", "upstream_fix": "kernel 6.1.88, kernel 6.6.29, kernel 6.8.3, kernel 6.9-rc2"}