CVE-2024-35980: Vulnerability in Linux Linux
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.
AI Analysis
Technical Summary
CVE-2024-35980 is a vulnerability in the Linux kernel specifically affecting the arm64 architecture's handling of the Translation Lookaside Buffer Invalidate (TLBI) RANGE operand. The issue arises in the Kernel-based Virtual Machine (KVM) implementation for arm64, which relies on the TLBI RANGE feature to flush TLBs during live migration of virtual machines (VMs). The vulnerability is caused by incorrect operand calculation passed to the TLBI RANGE instruction due to an incomplete implementation in the function __TLBI_RANGE_NUM(). This function fails to support the combination of SCALE#3 and NUM#31, which are parameters used to specify the range of pages to flush. As a result, the operand becomes invalid, leading to incomplete TLB flushes during live migration. This causes some dirty pages to be missed, ultimately resulting in a crash on the destination VM after migration. The problem manifests when large memory ranges are assigned to VMs (e.g., 8GB starting at 1GB address) and the TLB flush operation attempts to cover these ranges in one operation. The fix involves extending __TLBI_RANGE_NUM() to support the SCALE#3 and NUM#31 combination, allowing the TLB flush to cover 0x200000 page sizes correctly in a single operation. This correction prevents the operand underflow and invalid operand formation, ensuring complete TLB flushes and stable live migration. The vulnerability does not appear to have known exploits in the wild and is specific to arm64 KVM live migration scenarios on Linux kernels containing the faulty commit 117940aa6e5f. No CVSS score has been assigned yet.
Potential Impact
For European organizations utilizing Linux-based virtualization environments on arm64 hardware, this vulnerability could lead to instability and crashes during live migration of VMs. Live migration is critical for load balancing, maintenance, and high availability in data centers and cloud environments. A crash on the destination VM can cause service disruption, potential data loss, and downtime. Although this vulnerability does not directly lead to privilege escalation or data leakage, the availability impact can be significant for organizations relying on continuous VM operation. The issue is particularly relevant for cloud service providers, telecom operators, and enterprises deploying arm64-based infrastructure in Europe. Given the growing adoption of arm64 servers for energy efficiency and performance, the risk surface is expanding. However, exploitation requires specific conditions: use of KVM on arm64, live migration of VMs with large memory assignments, and presence of the vulnerable kernel version. The absence of known exploits reduces immediate risk but does not eliminate the potential for future attacks or operational failures.
Mitigation Recommendations
European organizations should promptly update their Linux kernels to versions that include the fix for CVE-2024-35980. Specifically, kernel versions that have patched the faulty commit 117940aa6e5f should be deployed. For environments where immediate patching is not feasible, temporary mitigation includes avoiding live migration of large-memory VMs on arm64 hosts or limiting VM memory sizes to reduce the likelihood of triggering the faulty TLBI RANGE operand. Additionally, organizations should audit their virtualization infrastructure to identify arm64 KVM hosts and verify kernel versions. Monitoring VM migration logs for crashes or anomalies can help detect exploitation or manifestation of the issue. Infrastructure teams should also test live migration workflows in staging environments after patching to ensure stability. Finally, maintaining a robust backup and disaster recovery plan is essential to mitigate potential data loss from unexpected VM crashes.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Finland, Norway, Denmark
CVE-2024-35980: Vulnerability in Linux Linux
Description
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.
AI-Powered Analysis
Technical Analysis
CVE-2024-35980 is a vulnerability in the Linux kernel specifically affecting the arm64 architecture's handling of the Translation Lookaside Buffer Invalidate (TLBI) RANGE operand. The issue arises in the Kernel-based Virtual Machine (KVM) implementation for arm64, which relies on the TLBI RANGE feature to flush TLBs during live migration of virtual machines (VMs). The vulnerability is caused by incorrect operand calculation passed to the TLBI RANGE instruction due to an incomplete implementation in the function __TLBI_RANGE_NUM(). This function fails to support the combination of SCALE#3 and NUM#31, which are parameters used to specify the range of pages to flush. As a result, the operand becomes invalid, leading to incomplete TLB flushes during live migration. This causes some dirty pages to be missed, ultimately resulting in a crash on the destination VM after migration. The problem manifests when large memory ranges are assigned to VMs (e.g., 8GB starting at 1GB address) and the TLB flush operation attempts to cover these ranges in one operation. The fix involves extending __TLBI_RANGE_NUM() to support the SCALE#3 and NUM#31 combination, allowing the TLB flush to cover 0x200000 page sizes correctly in a single operation. This correction prevents the operand underflow and invalid operand formation, ensuring complete TLB flushes and stable live migration. The vulnerability does not appear to have known exploits in the wild and is specific to arm64 KVM live migration scenarios on Linux kernels containing the faulty commit 117940aa6e5f. No CVSS score has been assigned yet.
Potential Impact
For European organizations utilizing Linux-based virtualization environments on arm64 hardware, this vulnerability could lead to instability and crashes during live migration of VMs. Live migration is critical for load balancing, maintenance, and high availability in data centers and cloud environments. A crash on the destination VM can cause service disruption, potential data loss, and downtime. Although this vulnerability does not directly lead to privilege escalation or data leakage, the availability impact can be significant for organizations relying on continuous VM operation. The issue is particularly relevant for cloud service providers, telecom operators, and enterprises deploying arm64-based infrastructure in Europe. Given the growing adoption of arm64 servers for energy efficiency and performance, the risk surface is expanding. However, exploitation requires specific conditions: use of KVM on arm64, live migration of VMs with large memory assignments, and presence of the vulnerable kernel version. The absence of known exploits reduces immediate risk but does not eliminate the potential for future attacks or operational failures.
Mitigation Recommendations
European organizations should promptly update their Linux kernels to versions that include the fix for CVE-2024-35980. Specifically, kernel versions that have patched the faulty commit 117940aa6e5f should be deployed. For environments where immediate patching is not feasible, temporary mitigation includes avoiding live migration of large-memory VMs on arm64 hosts or limiting VM memory sizes to reduce the likelihood of triggering the faulty TLBI RANGE operand. Additionally, organizations should audit their virtualization infrastructure to identify arm64 KVM hosts and verify kernel versions. Monitoring VM migration logs for crashes or anomalies can help detect exploitation or manifestation of the issue. Infrastructure teams should also test live migration workflows in staging environments after patching to ensure stability. Finally, maintaining a robust backup and disaster recovery plan is essential to mitigate potential data loss from unexpected VM crashes.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- Linux
- Date Reserved
- 2024-05-17T13:50:33.144Z
- Cisa Enriched
- true
- Cvss Version
- null
- State
- PUBLISHED
Threat ID: 682d9828c4522896dcbe236c
Added to database: 5/21/2025, 9:08:56 AM
Last enriched: 6/29/2025, 8:55:47 AM
Last updated: 7/29/2025, 11:38:13 PM
Views: 10
Related Threats
CVE-2025-9025: SQL Injection in code-projects Simple Cafe Ordering System
MediumCVE-2025-9024: SQL Injection in PHPGurukul Beauty Parlour Management System
MediumCVE-2025-9023: Buffer Overflow in Tenda AC7
HighCVE-2025-8905: CWE-94 Improper Control of Generation of Code ('Code Injection') in inpersttion Inpersttion For Theme
MediumCVE-2025-8720: CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in morehawes Plugin README Parser
MediumActions
Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.
External Links
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.