CVE-2024-35980

In the Linux kernel, the following vulnerability has been resolved: arm64:
tlb: Fix TLBI RANGE operand KVM/arm64 relies on TLBI RANGE feature to flush
TLBs when the dirty pages are collected by VMM and the page table entries
become write protected during live migration. Unfortunately, the operand
passed to the TLBI RANGE instruction isn’t correctly sorted out due to the
commit 117940aa6e5f (“KVM: arm64: Define kvm_tlb_flush_vmid_range()”). It
leads to crash on the destination VM after live migration because TLBs
aren’t flushed completely and some of the dirty pages are missed. For
example, I have a VM where 8GB memory is assigned, starting from 0x40000000
(1GB). Note that the host has 4KB as the base page size. In the middile of
migration, kvm_tlb_flush_vmid_range() is executed to flush TLBs. It passes
MAX_TLBI_RANGE_PAGES as the argument to __kvm_tlb_flush_vmid_range() and
__flush_s2_tlb_range_op(). SCALE#3 and NUM#31, corresponding to
MAX_TLBI_RANGE_PAGES, isn’t supported by __TLBI_RANGE_NUM(). In this
specific case, -1 has been returned from __TLBI_RANGE_NUM() for
SCALE#3/2/1/0 and rejected by the loop in the __flush_tlb_range_op() until
the variable @scale underflows and becomes -9, 0xffff708000040000 is set as
the operand. The operand is wrong since it’s sorted out by
__TLBI_VADDR_RANGE() according to invalid @scale and @num. Fix it by
extending __TLBI_RANGE_NUM() to support the combination of SCALE#3 and
NUM#31. With the changes, [-1 31] instead of [-1 30] can be returned from
the macro, meaning the TLBs for 0x200000 pages in the above example can be
flushed in one shoot with SCALE#3 and NUM#31. The macro TLBI_RANGE_MASK is
dropped since no one uses it any more. The comments are also adjusted
accordingly.