{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-53071", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-11-19T17:17:24.976Z", "datePublished": "2024-11-19T17:22:38.327Z", "dateUpdated": "2024-12-19T09:38:26.990Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-19T09:38:26.990Z"}, "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."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["drivers/gpu/drm/panthor/panthor_device.c"], "versions": [{"version": "5fe909cae118a757a77afb37174b99436a36d2e2", "lessThan": "2604afd65043e8f9d4be036cb1242adf6b5723cf", "status": "affected", "versionType": "git"}, {"version": "5fe909cae118a757a77afb37174b99436a36d2e2", "lessThan": "f432a1621f049bb207e78363d9d0e3c6fa2da5db", "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/panthor/panthor_device.c"], "versions": [{"version": "6.10", "status": "affected"}, {"version": "0", "lessThan": "6.10", "status": "unaffected", "versionType": "semver"}, {"version": "6.11.8", "lessThanOrEqual": "6.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.12", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "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"}}}}

{}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "ECA7D13C-A6AD-4239-BDEF-6B70FF23A4A9", "versionEndExcluding": "6.11.8", "versionStartIncluding": "6.10", "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", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "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\u00e1s estricto con las banderas de mapeo de IO La implementaci\u00f3n 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\u00e1 configurado, pero no borra VM_MAYWRITE. Eso significa que el espacio de usuario puede usar mprotect() para hacer que el mapeo sea escribible m\u00e1s tarde. Este es un problema cl\u00e1sico del controlador de Linux. No creo que esto realmente tenga alg\u00fan impacto en la pr\u00e1ctica: cuando la GPU est\u00e1 encendida, las escrituras en FLUSH_ID parecen ignorarse; y cuando la GPU no est\u00e1 encendida, la p\u00e1gina dummy_latest_flush proporcionada por el controlador est\u00e1 dise\u00f1ada deliberadamente para no hacer ning\u00fan vaciado, por lo que lo \u00fanico que escribir en dummy_latest_flush podr\u00eda lograr ser\u00eda hacer que ocurrieran *m\u00e1s* vaciados. 2. panthor_device_mmap_io() no bloquea las asignaciones MAP_PRIVATE (que son asignaciones sin el indicador VM_SHARED). MAP_PRIVATE en combinaci\u00f3n con VM_MAYWRITE indica que la VMA tiene sem\u00e1ntica de copia en escritura, que para VM_PFNMAP son semicompatibles pero con bastante mala calidad. En particular, en una asignaci\u00f3n de este tipo, el controlador solo puede instalar PTE durante mmap() llamando a remap_pfn_range() (porque remap_pfn_range() quiere **almacenar la direcci\u00f3n f\u00edsica de la memoria f\u00edsica asignada en el vm_pgoff de la VMA**); la instalaci\u00f3n de PTE m\u00e1s 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\u00f3n de este tipo, vmf_insert_pfn_prot() se bloquea cuando llega a una comprobaci\u00f3n de ERROR(). Arr\u00e9glelo borrando la marca VM_MAYWRITE (la escritura en el espacio de usuario en FLUSH_ID no tiene sentido) y requiriendo VM_SHARED (la sem\u00e1ntica de copia en escritura para FLUSH_ID no tiene sentido). Los reproductores para ambos escenarios est\u00e1n en las notas de mi parche en la lista de correo; prob\u00e9 que estos errores existen en una m\u00e1quina Rock 5B. Tenga en cuenta que solo prob\u00e9 la compilaci\u00f3n del parche, no lo he probado; a\u00fan no tengo una configuraci\u00f3n de compilaci\u00f3n de kernel que funcione para la m\u00e1quina de prueba. Pru\u00e9belo antes de aplicarlo."}], "id": "CVE-2024-53071", "lastModified": "2024-11-26T22:18:28.540", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 5.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2024-11-19T18:15:26.793", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "NVD-CWE-noinfo"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: drm/panthor: Be stricter about IO mapping flags", "id": "2327375", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2327375"}, "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": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\ndrm/panthor: Be stricter about IO mapping flags\nThe current panthor_device_mmap_io() implementation has two issues:\n1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,\npanthor_device_mmap_io() bails if VM_WRITE is set, but does not clear\nVM_MAYWRITE. That means userspace can use mprotect() to make the mapping\nwritable later on. This is a classic Linux driver gotcha.\nI don't think this actually has any impact in practice:\nWhen the GPU is powered, writes to the FLUSH_ID seem to be ignored; and\nwhen the GPU is not powered, the dummy_latest_flush page provided by the\ndriver is deliberately designed to not do any flushes, so the only thing\nwriting to the dummy_latest_flush could achieve would be to make *more*\nflushes happen.\n2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are\nmappings without the VM_SHARED flag).\nMAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has\ncopy-on-write semantics, which for VM_PFNMAP are semi-supported but\nfairly cursed.\nIn particular, in such a mapping, the driver can only install PTEs\nduring mmap() by calling remap_pfn_range() (because remap_pfn_range()\nwants to **store the physical address of the mapped physical memory into\nthe vm_pgoff of the VMA**); installing PTEs later on with a fault\nhandler (as panthor does) is not supported in private mappings, and so\nif you try to fault in such a mapping, vmf_insert_pfn_prot() splats when\nit hits a BUG() check.\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).\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.\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."], "name": "CVE-2024-53071", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-11-19T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-53071\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-53071\nhttps://lore.kernel.org/linux-cve-announce/2024111934-CVE-2024-53071-ddbc@gregkh/T"], "threat_severity": "Moderate"}