CVE-2024-35980

What it actually does

Incorrect computation of SCALE and NUM fields for the TLBI RANGE operand in __TLBI_RANGE_NUM and related KVM arm64 helpers causes incomplete TLB invalidation when flushing large ranges (e.g., MAX_TLBI_RANGE_PAGES), leaving stale TLB entries for dirty pages during live migration.

Why it matters to the business

Virtual machines using KVM on arm64 may crash immediately after live migration completes, causing unplanned downtime, service interruption, and potential data loss in virtualized environments that rely on memory migration.

How an attack unfolds

An attacker with the ability to initiate or influence live migration of a large-memory KVM guest (8 GB or more on 4 KB pages) can trigger kvm_tlb_flush_vmid_range with an unsupported SCALE/NUM combination; the resulting malformed TLBI operand leaves TLB entries unflushed, so the destination VM accesses stale mappings and crashes.

How to fix it

Apply the upstream fix in commit ac4ad513de4fba18b4ac0ace132777d0910e8cfa (extends __TLBI_RANGE_NUM to accept SCALE#3/NUM#31) or upgrade to a kernel that contains this commit; rebuild and reboot affected arm64 systems.

How to confirm the fix worked

Confirm the presence of commit ac4ad513de4fba18b4ac0ace132777d0910e8cfa in the running kernel source; test live migration of an 8 GB+ arm64 guest and verify no post-migration crashes occur; inspect __TLBI_RANGE_NUM macro definition for support of the 31-page count at SCALE 3.

Typical attack path

1. Attacker triggers or coerces live migration of an arm64 KVM guest with sufficient memory to require MAX_TLBI_RANGE_PAGES.
2. kvm_tlb_flush_vmid_range is called during dirty-page collection and write-protection phase.
3. __flush_s2_tlb_range_op receives an invalid scale/num pair and underflows, producing a malformed TLBI operand.
4. TLB entries for some dirty pages are not invalidated on the destination.
5. Destination VM resumes with inconsistent TLB state and crashes.

How to detect it

Review kernel logs on arm64 hosts for TLB flush errors or VM crashes immediately following live migration; correlate with KVM dirty-page logging and TLBI RANGE instruction usage; no public exploit artifacts or ransomware IOCs are known.

What your security team should do

• Prioritize patching arm64 KVM hosts within the next maintenance window due to migration-induced crash risk.
• Update to a kernel containing ac4ad513de4fba18b4ac0ace132777d0910e8cfa and verify via git log or package version.
• Monitor EPSS and any new threat-actor activity; re-evaluate if exploitation tooling emerges.
• Test migration workloads in a lab environment before production rollout.