First published: Tue Nov 19 2024(Updated: )
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.
Credit: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Affected Software | Affected Version | How to fix |
---|---|---|
Linux Kernel | >=6.10<6.11.8 | |
Linux Kernel | =6.12-rc1 | |
Linux Kernel | =6.12-rc2 | |
Linux Kernel | =6.12-rc3 | |
Linux Kernel | =6.12-rc4 | |
Linux Kernel | =6.12-rc5 | |
Linux Kernel | =6.12-rc6 | |
debian/linux | 5.10.223-1 5.10.226-1 6.1.123-1 6.1.128-1 6.12.12-1 6.12.15-1 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
CVE-2024-53071 has not been assigned a specific severity score yet, but it is important to address it due to potential impacts on system stability.
To fix CVE-2024-53071, you should update to a patched version of the Linux kernel as provided in the release notes.
CVE-2024-53071 affects Linux kernel versions from 6.10 to 6.11.8 and also includes several 6.12 release candidates.
CVE-2024-53071 impacts the DRM driver within the Linux kernel, specifically related to the io mapping flags in the panthor device.
CVE-2024-53071 is categorized as a local vulnerability, requiring local access to the affected system to exploit.