{
  "cveId": "CVE-2024-53071",
  "url": "https://patchblox.com/security/cve/CVE-2024-53071",
  "summary": "CVE-2024-53071 is fixed in linux on 1 platform, first by DEBIAN-CVE-2024-53071, released November 19, 2024. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  drm/panthor: Be stricter about IO mapping flags...",
  "description": "In the Linux kernel, the following vulnerability has been resolved:  drm/panthor: Be stricter about IO mapping flags  The current panthor_device_mmap_io() implementation has two issues:  1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,    panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear    VM_MAYWRITE. That means userspace can use mprotect() to make the mapping    writable later on. This is a classic Linux driver gotcha.    I don\u0027t think this actually has any impact in practice:    When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and    when the GPU is not powered, the dummy_latest_flush page provided by the    driver is deliberately designed to not do any flushes, so the only thing    writing to the dummy_latest_flush could achieve would be to make *more*    flushes happen.  2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are    mappings without the VM_SHARED flag).    MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has    copy-on-write semantics, which for VM_PFNMAP are semi-supported but    fairly cursed.    In particular, in such a mapping, the driver can only install PTEs    during mmap() by calling remap_pfn_range() (because remap_pfn_range()    wants to **store the physical address of the mapped physical memory into    the vm_pgoff of the VMA**); installing PTEs later on with a fault    handler (as panthor does) is not supported in private mappings, and so    if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when    it hits a BUG() check.  Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn\u0027t make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don\u0027t make sense).  Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine.  Note that I only compile-tested the patch, I haven\u0027t tested it; I don\u0027t have a working kernel build setup for the test machine yet. Please test it before applying it.",
  "published": "2024-11-19T18:15:26Z",
  "severity": "medium",
  "cvss": 5.5,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
  "epss": 0.00246,
  "epssPercentile": 0.15973,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.11.9-1",
      "fix": "DEBIAN-CVE-2024-53071",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2024-53071",
      "released": "2024-11-19T18:15:26Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "6.11.9-1",
      "fix": "DEBIAN-CVE-2024-53071",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2024-53071",
      "released": "2024-11-19T18:15:26Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-09T07:25:28Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}