ghsa-42c7-w7r7-3v3m
Vulnerability from github
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:
-
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.
-
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.
{ affected: [], aliases: [ "CVE-2024-53071", ], database_specific: { cwe_ids: [], github_reviewed: false, github_reviewed_at: null, nvd_published_at: "2024-11-19T18:15:26Z", severity: "MODERATE", }, details: "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.", id: "GHSA-42c7-w7r7-3v3m", modified: "2024-11-27T00:31:41Z", published: "2024-11-19T18:31:07Z", references: [ { type: "ADVISORY", url: "https://nvd.nist.gov/vuln/detail/CVE-2024-53071", }, { type: "WEB", url: "https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf", }, { type: "WEB", url: "https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db", }, ], schema_version: "1.4.0", severity: [ { score: "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", type: "CVSS_V3", }, ], }
Log in or create an account to share your comment.
This schema specifies the format of a comment related to a security advisory.
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.