cve-2024-53071
Vulnerability from cvelistv5
Published
2024-11-19 17:22
Modified
2024-12-19 09:38
Severity ?
Summary
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't 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't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't 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't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cfPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5dbPatch
Impacted products
Vendor Product Version
Linux Linux Version: 5fe909cae118a757a77afb37174b99436a36d2e2
Version: 5fe909cae118a757a77afb37174b99436a36d2e2
 Create a notification for this product.
   Linux Linux Version: 6.10
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
   containers: {
      cna: {
         affected: [
            {
               defaultStatus: "unaffected",
               product: "Linux",
               programFiles: [
                  "drivers/gpu/drm/panthor/panthor_device.c",
               ],
               repo: "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
               vendor: "Linux",
               versions: [
                  {
                     lessThan: "2604afd65043e8f9d4be036cb1242adf6b5723cf",
                     status: "affected",
                     version: "5fe909cae118a757a77afb37174b99436a36d2e2",
                     versionType: "git",
                  },
                  {
                     lessThan: "f432a1621f049bb207e78363d9d0e3c6fa2da5db",
                     status: "affected",
                     version: "5fe909cae118a757a77afb37174b99436a36d2e2",
                     versionType: "git",
                  },
               ],
            },
            {
               defaultStatus: "affected",
               product: "Linux",
               programFiles: [
                  "drivers/gpu/drm/panthor/panthor_device.c",
               ],
               repo: "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
               vendor: "Linux",
               versions: [
                  {
                     status: "affected",
                     version: "6.10",
                  },
                  {
                     lessThan: "6.10",
                     status: "unaffected",
                     version: "0",
                     versionType: "semver",
                  },
                  {
                     lessThanOrEqual: "6.11.*",
                     status: "unaffected",
                     version: "6.11.8",
                     versionType: "semver",
                  },
                  {
                     lessThanOrEqual: "*",
                     status: "unaffected",
                     version: "6.12",
                     versionType: "original_commit_for_fix",
                  },
               ],
            },
         ],
         descriptions: [
            {
               lang: "en",
               value: "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/panthor: Be stricter about IO mapping flags\n\nThe current panthor_device_mmap_io() implementation has two issues:\n\n1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,\n   panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear\n   VM_MAYWRITE. That means userspace can use mprotect() to make the mapping\n   writable later on. This is a classic Linux driver gotcha.\n   I don't think this actually has any impact in practice:\n   When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and\n   when the GPU is not powered, the dummy_latest_flush page provided by the\n   driver is deliberately designed to not do any flushes, so the only thing\n   writing to the dummy_latest_flush could achieve would be to make *more*\n   flushes happen.\n\n2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are\n   mappings without the VM_SHARED flag).\n   MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has\n   copy-on-write semantics, which for VM_PFNMAP are semi-supported but\n   fairly cursed.\n   In particular, in such a mapping, the driver can only install PTEs\n   during mmap() by calling remap_pfn_range() (because remap_pfn_range()\n   wants to **store the physical address of the mapped physical memory into\n   the vm_pgoff of the VMA**); installing PTEs later on with a fault\n   handler (as panthor does) is not supported in private mappings, and so\n   if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when\n   it hits a BUG() check.\n\nFix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID\ndoesn't make sense) and requiring VM_SHARED (copy-on-write semantics for\nthe FLUSH_ID don't make sense).\n\nReproducers for both scenarios are in the notes of my patch on the mailing\nlist; I tested that these bugs exist on a Rock 5B machine.\n\nNote that I only compile-tested the patch, I haven't tested it; I don't\nhave a working kernel build setup for the test machine yet. Please test it\nbefore applying it.",
            },
         ],
         providerMetadata: {
            dateUpdated: "2024-12-19T09:38:26.990Z",
            orgId: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            shortName: "Linux",
         },
         references: [
            {
               url: "https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf",
            },
            {
               url: "https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db",
            },
         ],
         title: "drm/panthor: Be stricter about IO mapping flags",
         x_generator: {
            engine: "bippy-5f407fcff5a0",
         },
      },
   },
   cveMetadata: {
      assignerOrgId: "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      assignerShortName: "Linux",
      cveId: "CVE-2024-53071",
      datePublished: "2024-11-19T17:22:38.327Z",
      dateReserved: "2024-11-19T17:17:24.976Z",
      dateUpdated: "2024-12-19T09:38:26.990Z",
      state: "PUBLISHED",
   },
   dataType: "CVE_RECORD",
   dataVersion: "5.1",
   "vulnerability-lookup:meta": {
      nvd: "{\"cve\":{\"id\":\"CVE-2024-53071\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-11-19T18:15:26.793\",\"lastModified\":\"2024-11-26T22:18:28.540\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\ndrm/panthor: Be stricter about IO mapping flags\\n\\nThe current panthor_device_mmap_io() implementation has two issues:\\n\\n1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,\\n   panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear\\n   VM_MAYWRITE. That means userspace can use mprotect() to make the mapping\\n   writable later on. This is a classic Linux driver gotcha.\\n   I don't think this actually has any impact in practice:\\n   When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and\\n   when the GPU is not powered, the dummy_latest_flush page provided by the\\n   driver is deliberately designed to not do any flushes, so the only thing\\n   writing to the dummy_latest_flush could achieve would be to make *more*\\n   flushes happen.\\n\\n2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are\\n   mappings without the VM_SHARED flag).\\n   MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has\\n   copy-on-write semantics, which for VM_PFNMAP are semi-supported but\\n   fairly cursed.\\n   In particular, in such a mapping, the driver can only install PTEs\\n   during mmap() by calling remap_pfn_range() (because remap_pfn_range()\\n   wants to **store the physical address of the mapped physical memory into\\n   the vm_pgoff of the VMA**); installing PTEs later on with a fault\\n   handler (as panthor does) is not supported in private mappings, and so\\n   if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when\\n   it hits a BUG() check.\\n\\nFix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID\\ndoesn't make sense) and requiring VM_SHARED (copy-on-write semantics for\\nthe FLUSH_ID don't make sense).\\n\\nReproducers for both scenarios are in the notes of my patch on the mailing\\nlist; I tested that these bugs exist on a Rock 5B machine.\\n\\nNote that I only compile-tested the patch, I haven't tested it; I don't\\nhave a working kernel build setup for the test machine yet. Please test it\\nbefore applying it.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/panthor: Sea más estricto con las banderas de mapeo de IO La implementación actual de panthor_device_mmap_io() tiene dos problemas: 1. Para mapear DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() abandona si VM_WRITE está configurado, pero no borra VM_MAYWRITE. Eso significa que el espacio de usuario puede usar mprotect() para hacer que el mapeo sea escribible más tarde. Este es un problema clásico del controlador de Linux. No creo que esto realmente tenga algún impacto en la práctica: cuando la GPU está encendida, las escrituras en FLUSH_ID parecen ignorarse; y cuando la GPU no está encendida, la página dummy_latest_flush proporcionada por el controlador está diseñada deliberadamente para no hacer ningún vaciado, por lo que lo único que escribir en dummy_latest_flush podría lograr sería hacer que ocurrieran *más* vaciados. 2. panthor_device_mmap_io() no bloquea las asignaciones MAP_PRIVATE (que son asignaciones sin el indicador VM_SHARED). MAP_PRIVATE en combinación con VM_MAYWRITE indica que la VMA tiene semántica de copia en escritura, que para VM_PFNMAP son semicompatibles pero con bastante mala calidad. En particular, en una asignación de este tipo, el controlador solo puede instalar PTE durante mmap() llamando a remap_pfn_range() (porque remap_pfn_range() quiere **almacenar la dirección física de la memoria física asignada en el vm_pgoff de la VMA**); la instalación de PTE más tarde con un controlador de errores (como lo hace panthor) no se admite en asignaciones privadas y, por lo tanto, si intenta generar un error en una asignación de este tipo, vmf_insert_pfn_prot() se bloquea cuando llega a una comprobación de ERROR(). Arréglelo borrando la marca VM_MAYWRITE (la escritura en el espacio de usuario en FLUSH_ID no tiene sentido) y requiriendo VM_SHARED (la semántica de copia en escritura para FLUSH_ID no tiene sentido). Los reproductores para ambos escenarios están en las notas de mi parche en la lista de correo; probé que estos errores existen en una máquina Rock 5B. Tenga en cuenta que solo probé la compilación del parche, no lo he probado; aún no tengo una configuración de compilación de kernel que funcione para la máquina de prueba. Pruébelo antes de aplicarlo.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.10\",\"versionEndExcluding\":\"6.11.8\",\"matchCriteriaId\":\"ECA7D13C-A6AD-4239-BDEF-6B70FF23A4A9\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"7F361E1D-580F-4A2D-A509-7615F73167A1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"925478D0-3E3D-4E6F-ACD5-09F28D5DF82C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"3C95E234-D335-4B6C-96BF-E2CEBD8654ED\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"E0F717D8-3014-4F84-8086-0124B2111379\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"24DBE6C7-2AAE-4818-AED2-E131F153D2FA\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.12:rc6:*:*:*:*:*:*\",\"matchCriteriaId\":\"24B88717-53F5-42AA-9B72-14C707639E3F\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}",
   },
}


Log in or create an account to share your comment.

Security Advisory comment format.

This schema specifies the format of a comment related to a security advisory.

UUIDv4 of the comment
UUIDv4 of the Vulnerability-Lookup instance
When the comment was created originally
When the comment was last updated
Title of the comment
Description of the comment
The identifier of the vulnerability (CVE ID, GHSA-ID, PYSEC ID, etc.).



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.
  • 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.