arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults
Platform
linux
Component
linux
Fixed in
97c5550b763171dbef61e6239cab372b9f9cd4a2
In the Linux kernel, the following vulnerability has been resolved:
arm64: contpte: fix setaccessflags() no-op check for SMMU/ATS faults
contpteptepsetaccessflags() compared the gathered ptep_get() value against the requested entry to detect no-ops. ptep_get() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTE_RDONLY set in hardware.
For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop.
Gathering can therefore cause false no-ops when only a sibling has been updated: - write faults: target still has PTERDONLY (needs PTERDONLY cleared) - read faults: target still lacks PTE_AF
Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by _ptepsetaccessflags()), using raw per-PTE values rather than the gathered ptep_get() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision.
Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range.
Affected Software
Timeline
- Reserved
- Published
How to fix
Aplicar la actualización del kernel a la versión 6.9 o superior. Esta actualización corrige un error en el manejo de las señales de fallo de la SMMU/ATS, evitando un posible bucle infinito de fallos en ciertas configuraciones de hardware.
Is your project affected?
Upload your dependency file and we'll tell you instantly if this and other CVEs hit you.
Try it now — no account
Upload any manifest (composer.lock, package-lock.json, WordPress plugin list…) or paste your component list. You get a vulnerability report instantly. Uploading a file is just the start: with an account you get continuous monitoring, Slack/email alerts, multi-project and white-label reports.
Drag & drop your dependency file
composer.lock, package-lock.json, requirements.txt, Gemfile.lock, pubspec.lock, Dockerfile...