Vulnerability · Published Nov 19, 2024 · Assigned by Linux
CVE-2024-53071drm/panthor: Be stricter about IO mapping flags
Medium 5.5
In plain English
A medium-severity security flaw in Linux from Linux. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.2% (higher than 16% of all known vulnerabilities). Ready-made attack tooling exists: public proof-of-concept code. Fixed versions are available - upgrade the affected package.
Official description
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.
Affected packages & fixed versions
| Ecosystem | Package | Fixed in | Advisory |
|---|---|---|---|
| Debian:13 | linux | 6.11.9-1 | DEBIAN-CVE-2024-53071 |
| Debian:14 | linux | 6.11.9-1 | DEBIAN-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-allwinner-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-aws-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-aws-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-aws-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-azure-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-azure-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-azure-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-azure-fde-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-azure-fde-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-gcp-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-gcp-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-gcp-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-hwe-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-hwe-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-hwe-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-intel-iot-realtime | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-lowlatency-hwe-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-lowlatency-hwe-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-lowlatency-hwe-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-nvidia-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-nvidia-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-oem-5.17 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-oem-6.0 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-oem-6.1 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:24.04:LTS | linux-oem-6.11 | 6.11.0-1015.15 | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-oem-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-oracle-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:24.04:LTS | linux-raspi-realtime | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-realtime | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-riscv | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-riscv-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-riscv-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-starfive-5.19 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-starfive-6.2 | no fix listed | UBUNTU-CVE-2024-53071 |
| Ubuntu:22.04:LTS | linux-starfive-6.5 | no fix listed | UBUNTU-CVE-2024-53071 |