{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-40924",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-40924"
  ],
  "published": "2024-07-12T12:27:31Z",
  "summary": "drm/i915/dpt: Make DPT object unshrinkable",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/dpt: Make DPT object unshrinkable\n\nIn some scenarios, the DPT object gets shrunk but\nthe actual framebuffer did not and thus its still\nthere on the DPT's vm->bound_list. Then it tries to\nrewrite the PTEs via a stale CPU mapping. This causes panic.\n\n[vsyrjala: Add TODO comment]\n(cherry picked from commit 51064d471c53dcc8eddd2333c3f1c1d9131ba36c)",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.95",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-40924"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/327280149066f0e5f2e50356b5823f76dabfe86e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/7a9883be3b98673333eec65c4a21cc18e60292eb"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a2552020fb714ff357182c3c179abfac2289f84d"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/43e2b37e2ab660c3565d4cff27922bc70e79c3f1"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - Exploitation requires local access to the i915 DRM device node (`/dev/dri/card0`) via the ADDFB2 ioctl plus locally generated memory pressure and a suspend/resume cycle. There is no network-reachable path into `intel_dpt_create()`/`intel_dpt_resume()`.\nAC:L - The attacker controls every input: creating many DPT-backed framebuffers via ADDFB2 exhausts stolen memory to force the shrinkable shmem DPT path, anonymous memory allocation drives kswapd's `I915_SHRINK_ACTIVE` pass that evicts the DPT object, and logind lets an active local session initiate suspend/resume on demand, with unlimited retries.\nPR:L - An unprivileged local user with a graphical session holds an open primary DRM node (ADDFB2 has ioctl flags 0 \u2014 neither DRM_MASTER nor CAP_SYS_ADMIN is checked) and can allocate memory and request suspend; no root or capability is needed.\nUI:N - The bound framebuffer vma on the DPT vm's `bound_list` is the normal steady state of any running compositor, and the attacker can drive both the shrink and the suspend/resume itself via logind or the RTC wakealarm. No victim action is required.\nS:U - The dangling write and the resulting corruption are confined to the kernel's own address space and the same i915 device; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Corrupted/stale DPT page-table entries make the display engine fetch arbitrary physical pages for scanout, disclosing kernel and other-process memory, and the use-after-free write into reused vmalloc/ioremap space can be leveraged to expose memory contents.\nI:H - `dpt_insert_entries()` performs many 64-bit `writeq()` operations at an attacker-influenced index with attacker-influenced PTE values through a freed kernel mapping, a use-after-free/out-of-bounds write primitive usable for control-flow corruption once the VA range is reused.\nA:H - The fix commit states plainly that rewriting PTEs via the stale CPU mapping \"causes panic,\" and the related commit reports \"an immediate oops during hibernate,\" i.e. a full kernel crash on the resume path."
    }
  }
}