CVE-2024-53071

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: Be stricter about IO mapping flags<br /> <br /> The current panthor_device_mmap_io() implementation has two issues:<br /> <br /> 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET,<br /> panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear<br /> VM_MAYWRITE. That means userspace can use mprotect() to make the mapping<br /> writable later on. This is a classic Linux driver gotcha.<br /> I don&amp;#39;t think this actually has any impact in practice:<br /> When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and<br /> when the GPU is not powered, the dummy_latest_flush page provided by the<br /> driver is deliberately designed to not do any flushes, so the only thing<br /> writing to the dummy_latest_flush could achieve would be to make *more*<br /> flushes happen.<br /> <br /> 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are<br /> mappings without the VM_SHARED flag).<br /> MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has<br /> copy-on-write semantics, which for VM_PFNMAP are semi-supported but<br /> fairly cursed.<br /> In particular, in such a mapping, the driver can only install PTEs<br /> during mmap() by calling remap_pfn_range() (because remap_pfn_range()<br /> wants to **store the physical address of the mapped physical memory into<br /> the vm_pgoff of the VMA**); installing PTEs later on with a fault<br /> handler (as panthor does) is not supported in private mappings, and so<br /> if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when<br /> it hits a BUG() check.<br /> <br /> Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID<br /> doesn&amp;#39;t make sense) and requiring VM_SHARED (copy-on-write semantics for<br /> the FLUSH_ID don&amp;#39;t make sense).<br /> <br /> Reproducers for both scenarios are in the notes of my patch on the mailing<br /> list; I tested that these bugs exist on a Rock 5B machine.<br /> <br /> Note that I only compile-tested the patch, I haven&amp;#39;t tested it; I don&amp;#39;t<br /> have a working kernel build setup for the test machine yet. Please test it<br /> before applying it.