CVE-2024-26939 (GCVE-0-2024-26939)
Vulnerability from cvelistv5
Published
2024-05-01 05:17
Modified
2026-08-05 11:28
Severity ?
7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: drm/i915/vma: Fix UAF on destroy against retire race Object debugging tools were sporadically reporting illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle. [161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915] [161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0 ... [161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1 [161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022 [161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915] [161.360592] RIP: 0010:debug_print_object+0x80/0xb0 ... [161.361347] debug_object_free+0xeb/0x110 [161.361362] i915_active_fini+0x14/0x130 [i915] [161.361866] release_references+0xfe/0x1f0 [i915] [161.362543] i915_vma_parked+0x1db/0x380 [i915] [161.363129] __gt_park+0x121/0x230 [i915] [161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915] That has been tracked down to be happening when another thread is deactivating the VMA inside __active_retire() helper, after the VMA's active counter has been already decremented to 0, but before deactivation of the VMA's object is reported to the object debugging tool. We could prevent from that race by serializing i915_active_fini() with __active_retire() via ref->tree_lock, but that wouldn't stop the VMA from being used, e.g. from __i915_vma_retire() called at the end of __active_retire(), after that VMA has been already freed by a concurrent i915_vma_destroy() on return from the i915_active_fini(). Then, we should rather fix the issue at the VMA level, not in i915_active. Since __i915_vma_parked() is called from __gt_park() on last put of the GT's wakeref, the issue could be addressed by holding the GT wakeref long enough for __active_retire() to complete before that wakeref is released and the GT parked. I believe the issue was introduced by commit d93939730347 ("drm/i915: Remove the vma refcount") which moved a call to i915_active_fini() from a dropped i915_vma_release(), called on last put of the removed VMA kref, to i915_vma_parked() processing path called on last put of a GT wakeref. However, its visibility to the object debugging tool was suppressed by a bug in i915_active that was fixed two weeks later with commit e92eb246feb9 ("drm/i915/active: Fix missing debug object activation"). A VMA associated with a request doesn't acquire a GT wakeref by itself. Instead, it depends on a wakeref held directly by the request's active intel_context for a GT associated with its VM, and indirectly on that intel_context's engine wakeref if the engine belongs to the same GT as the VMA's VM. Those wakerefs are released asynchronously to VMA deactivation. Fix the issue by getting a wakeref for the VMA's GT when activating it, and putting that wakeref only after the VMA is deactivated. However, exclude global GTT from that processing path, otherwise the GPU never goes idle. Since __i915_vma_retire() may be called from atomic contexts, use async variant of wakeref put. Also, to avoid circular locking dependency, take care of acquiring the wakeref before VM mutex when both are needed. v7: Add inline comments with justifications for: - using untracked variants of intel_gt_pm_get/put() (Nirmoy), - using async variant of _put(), - not getting the wakeref in case of a global GTT, - always getting the first wakeref outside vm->mutex. v6: Since __i915_vma_active/retire() callbacks are not serialized, storing a wakeref tracking handle inside struct i915_vma is not safe, and there is no other good place for that. Use untracked variants of intel_gt_pm_get/put_async(). v5: Replace "tile" with "GT" across commit description (Rodrigo), - ---truncated---
References
Impacted products
Vendor Product Version
Linux Linux Version: d93939730347360db0afe6a4367451b6f84ab7b1
Version: d93939730347360db0afe6a4367451b6f84ab7b1
Version: d93939730347360db0afe6a4367451b6f84ab7b1
Version: d93939730347360db0afe6a4367451b6f84ab7b1
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-26939",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-06-06T18:59:58.125327Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-416",
                "description": "CWE-416 Use After Free",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-06T19:00:13.886Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T00:21:05.670Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "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"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/i915/i915_vma.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "704edc9252f4988ae1ad7dafa23d0db8d90d7190",
              "status": "affected",
              "version": "d93939730347360db0afe6a4367451b6f84ab7b1",
              "versionType": "git"
            },
            {
              "lessThan": "5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5",
              "status": "affected",
              "version": "d93939730347360db0afe6a4367451b6f84ab7b1",
              "versionType": "git"
            },
            {
              "lessThan": "59b2626dd8c8a2e13f18054b3530e0c00073d79f",
              "status": "affected",
              "version": "d93939730347360db0afe6a4367451b6f84ab7b1",
              "versionType": "git"
            },
            {
              "lessThan": "0e45882ca829b26b915162e8e86dbb1095768e9e",
              "status": "affected",
              "version": "d93939730347360db0afe6a4367451b6f84ab7b1",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/gpu/drm/i915/i915_vma.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.19"
            },
            {
              "lessThan": "5.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.88",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.29",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.8.*",
              "status": "unaffected",
              "version": "6.8.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.9",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.88",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.29",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.8.3",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.9",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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\u0027s\nactive counter has been already decremented to 0, but before deactivation\nof the VMA\u0027s 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\u0027t 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\u0027s 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\u0027t acquire a GT wakeref by itself.\nInstead, it depends on a wakeref held directly by the request\u0027s active\nintel_context for a GT associated with its VM, and indirectly on that\nintel_context\u0027s engine wakeref if the engine belongs to the same GT as the\nVMA\u0027s VM.  Those wakerefs are released asynchronously to VMA deactivation.\n\nFix the issue by getting a wakeref for the VMA\u0027s 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---"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The vulnerability is reached through DRM ioctls (I915_GEM_EXECBUFFER2, context/vm create-destroy, GEM handle close) on /dev/dri/renderD128 or /dev/dri/card0, requiring local access to the machine. There is no network-facing path into the i915 VMA lifecycle.\nAC:L - The attacker controls both sides of the race \u2014 GPU batch submission drives request retirement (__active_retire), while closing handles/contexts and letting the GPU idle drives __gt_park() \u2192 i915_vma_parked() \u2192 i915_vma_free() \u2014 and can loop it indefinitely across CPUs with a large closed_vma list to widen the window. Intel CI hit this race spontaneously without any adversarial timing.\nPR:L - All required ioctls are marked DRM_RENDER_ALLOW, so any unprivileged local user with render-node access (standard for any desktop/graphical user, Android app, or container with /dev/dri passed through) can reach the code with no capabilities. No DRM_MASTER, CAP_SYS_ADMIN, or root is needed.\nUI:N - The attacking process performs every step itself \u2014 creating objects and contexts, submitting batches, closing handles, and idling the GPU. No victim action is involved.\nS:U - The use-after-free corrupts kernel slab memory and its impact stays within the host kernel\u0027s security authority. The GVT virtualization path uses GGTT-pinned VMAs, which the fix explicitly excludes, so no guest-to-host boundary is crossed.\nC:H - After the VMA slab object is freed and reallocated, __active_retire() and __i915_vma_retire() read the ref-\u003eretire function pointer and vma-\u003eobj from freed memory, which combined with heap spraying of the mergeable slab_vmas cache yields kernel information disclosure and arbitrary-read primitives.\nI:H - The freed-memory read of ref-\u003eretire is immediately followed by an indirect call through it, and vma-\u003eobj is loaded from freed memory and passed to kref_put() \u2014 giving both control-flow hijack and arbitrary-decrement/premature-free primitives that lead to privilege escalation.\nA:H - The bug is a slab use-after-free that manifests as a debugobjects WARNING and reliably oopses or panics the kernel (KASAN reports slab-use-after-free), and it can be triggered repeatedly by an unprivileged process to take the system down."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T11:28:28.848Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "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-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2024-26939",
    "datePublished": "2024-05-01T05:17:44.370Z",
    "dateReserved": "2024-02-19T14:20:24.196Z",
    "dateUpdated": "2026-08-05T11:28:28.848Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "vulnrichment": {
      "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\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 7.8, \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The vulnerability is reached through DRM ioctls (I915_GEM_EXECBUFFER2, context/vm create-destroy, GEM handle close) on /dev/dri/renderD128 or /dev/dri/card0, requiring local access to the machine. There is no network-facing path into the i915 VMA lifecycle.\\nAC:L - The attacker controls both sides of the race \\u2014 GPU batch submission drives request retirement (__active_retire), while closing handles/contexts and letting the GPU idle drives __gt_park() \\u2192 i915_vma_parked() \\u2192 i915_vma_free() \\u2014 and can loop it indefinitely across CPUs with a large closed_vma list to widen the window. Intel CI hit this race spontaneously without any adversarial timing.\\nPR:L - All required ioctls are marked DRM_RENDER_ALLOW, so any unprivileged local user with render-node access (standard for any desktop/graphical user, Android app, or container with /dev/dri passed through) can reach the code with no capabilities. No DRM_MASTER, CAP_SYS_ADMIN, or root is needed.\\nUI:N - The attacking process performs every step itself \\u2014 creating objects and contexts, submitting batches, closing handles, and idling the GPU. No victim action is involved.\\nS:U - The use-after-free corrupts kernel slab memory and its impact stays within the host kernel\u0027s security authority. The GVT virtualization path uses GGTT-pinned VMAs, which the fix explicitly excludes, so no guest-to-host boundary is crossed.\\nC:H - After the VMA slab object is freed and reallocated, __active_retire() and __i915_vma_retire() read the ref-\u003eretire function pointer and vma-\u003eobj from freed memory, which combined with heap spraying of the mergeable slab_vmas cache yields kernel information disclosure and arbitrary-read primitives.\\nI:H - The freed-memory read of ref-\u003eretire is immediately followed by an indirect call through it, and vma-\u003eobj is loaded from freed memory and passed to kref_put() \\u2014 giving both control-flow hijack and arbitrary-decrement/premature-free primitives that lead to privilege escalation.\\nA:H - The bug is a slab use-after-free that manifests as a debugobjects WARNING and reliably oopses or panics the kernel (KASAN reports slab-use-after-free), and it can be triggered repeatedly by an unprivileged process to take the system down.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"d93939730347360db0afe6a4367451b6f84ab7b1\", \"lessThan\": \"704edc9252f4988ae1ad7dafa23d0db8d90d7190\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"d93939730347360db0afe6a4367451b6f84ab7b1\", \"lessThan\": \"5e3eb862df9f972ab677fb19e0d4b9b1be8db7b5\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"d93939730347360db0afe6a4367451b6f84ab7b1\", \"lessThan\": \"59b2626dd8c8a2e13f18054b3530e0c00073d79f\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"d93939730347360db0afe6a4367451b6f84ab7b1\", \"lessThan\": \"0e45882ca829b26b915162e8e86dbb1095768e9e\", \"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-1.2.0\"}, \"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\u0027s\\nactive counter has been already decremented to 0, but before deactivation\\nof the VMA\u0027s 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\u0027t 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\u0027s 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\u0027t acquire a GT wakeref by itself.\\nInstead, it depends on a wakeref held directly by the request\u0027s active\\nintel_context for a GT associated with its VM, and indirectly on that\\nintel_context\u0027s engine wakeref if the engine belongs to the same GT as the\\nVMA\u0027s VM.  Those wakerefs are released asynchronously to VMA deactivation.\\n\\nFix the issue by getting a wakeref for the VMA\u0027s 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---\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1.88\", \"versionStartIncluding\": \"5.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.6.29\", \"versionStartIncluding\": \"5.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.8.3\", \"versionStartIncluding\": \"5.19\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.9\", \"versionStartIncluding\": \"5.19\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T11:28:28.848Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2024-26939\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-08-05T11:28:28.848Z\", \"dateReserved\": \"2024-02-19T14:20:24.196Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2024-05-01T05:17:44.370Z\", \"assignerShortName\": \"Linux\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.