CVE-2024-35980

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