VDB

DEBIAN-CVE-2024-53071

DEBIAN-CVE-2024-53071 PUBLISHED CVSS 5.5 MEDIUM

Record from OSV · Published November 19, 2024

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.

Fixed versions

Upgrade to a fixed version or later. Language registries are listed first, then Linux distributions, then vendor products.

PackageEcosystemFixed in
linuxDebian:136.11.9-1
linuxDebian:146.11.9-1

Risk scores

CVSS 3.1
5.5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected products

VendorProductVersions
Debian:13linux0
Debian:14linux0

Timeline

  • Nov 19, 2024 CVE Published
  • Sep 15, 2026 CVE Updated

Query this with the API

The same record, from the CLI:

vulnetix vdb vuln DEBIAN-CVE-2024-53071
vulnetix vdb fixes DEBIAN-CVE-2024-53071

Or with curl, using the org id and key from your account page:

curl -s -H "Authorization: ApiKey ${VULNETIX_ORG_ID}:${VULNETIX_API_KEY}" \
  "https://api.vdb.vulnetix.com/v2/vuln/DEBIAN-CVE-2024-53071/fixes/registry"

The Community plan is free and allows 50 queries a day. Get a free API key · API quickstart

Look up in the Resolve Platform →
$ Lookup Community · 50/day Open Lookup ›