GPU VulnDB

Database/Kernel, userspace & hypervisor

Arm CPUs: broadcast TLBI;DSB may complete before writes under an invalidated entry are globally observed

CVSS 8.8CVE-2026-53354Kernel, userspace & hypervisorcurated

Impact

Several Arm-designed CPU cores let a broadcast TLBI followed by DSB report completion before memory writes translated by the invalidated TLB entry are globally observed. TLB entries are removed correctly - the defect is purely in the completion guarantee, which is exactly what software relies on when it unmaps a page and then assumes nobody can still see stale writes to it. That is the ordering assumption behind page reclaim, copy-on-write and stage-2 unmap, so on a shared arm64 GPU node it undermines the boundary between a tenant's freed pages and the next owner of that memory. The defect is in silicon; Linux mitigates it by issuing a second TLBI;DSB (ARM64_WORKAROUND_REPEAT_TLBI) on affected cores. Arm tracks the underlying issue as CVE-2025-10263, and because of how Arm numbers errata several different cores share one erratum id.

Who can reach it

Local on the host: an unprivileged local user or guest on an affected arm64 CPU whose workload can race a TLB invalidation. No authentication beyond code execution on the node; not reachable over the network.

What to do

Update to a stable kernel that enables ARM64_WORKAROUND_REPEAT_TLBI for your cores (five stable commits are linked) and reboot - the workaround is selected at boot from CPU identification, so it cannot be turned on at runtime. There is no silicon fix; check your CPU against the kernel's silicon-errata documentation to see whether your parts are listed before scheduling the window. Expect a small cost on TLB-invalidation-heavy workloads from the extra TLBI;DSB.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.