cveboard Feed RSS

CVE-2024-53071

CVE.org · Publicado

Histórico de CVEsJSONInstruções para IA

Status do registro
Publicado
Ano do identificador (não é o ano de publicação)
2024
Publicação na fonte
Atualização na fonte
Importado pelo cveboard
Snapshot da fonte
cve_2026-10-24_midnight_baseline ·

Texto simples

Texto da CNA em inglês

drm/panthor: Be stricter about IO mapping flags

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.

Fatos de produtos e versões por escopo

Dados de correção desconhecidos; nenhuma versão corrigida é deduzida aqui. Dados ausentes não comprovam ausência de correção.

Exploração desconhecida; este catálogo não avalia exploração.

Linux

Fornecedor
Linux
Produto
Linux
Plataformas
Desconhecido
Status padrão
unaffected
Linux · Fatos de produtos e versões por escopo
Versão (version)Status (status)Esquema de versões (versionType)Fim exclusivo (lessThan)Fim inclusivo (lessThanOrEqual)Mudanças de status (at → status)
5fe909cae118a757a77afb37174b99436a36d2e2affectedgit2604afd65043e8f9d4be036cb1242adf6b5723cfIndisponívelNenhuma listada
5fe909cae118a757a77afb37174b99436a36d2e2affectedgitf432a1621f049bb207e78363d9d0e3c6fa2da5dbIndisponívelNenhuma listada

Linux

Fornecedor
Linux
Produto
Linux
Plataformas
Desconhecido
Status padrão
affected
Linux · Fatos de produtos e versões por escopo
Versão (version)Status (status)Esquema de versões (versionType)Fim exclusivo (lessThan)Fim inclusivo (lessThanOrEqual)Mudanças de status (at → status)
6.10affectedIndisponívelIndisponívelIndisponívelNenhuma listada
0unaffectedsemver6.10IndisponívelNenhuma listada
6.11.8unaffectedsemverIndisponível6.11.*Nenhuma listada
6.12unaffectedoriginal_commit_for_fixIndisponível*Nenhuma listada