{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-35980", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-05-17T13:50:33.144Z", "datePublished": "2024-05-20T09:42:05.085Z", "dateUpdated": "2024-12-19T08:59:32.992Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-12-19T08:59:32.992Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: tlb: Fix TLBI RANGE operand\n\nKVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty\npages are collected by VMM and the page table entries become write\nprotected during live migration. Unfortunately, the operand passed\nto the TLBI RANGE instruction isn't correctly sorted out due to the\ncommit 117940aa6e5f (\"KVM: arm64: Define kvm_tlb_flush_vmid_range()\").\nIt leads to crash on the destination VM after live migration because\nTLBs aren't flushed completely and some of the dirty pages are missed.\n\nFor example, I have a VM where 8GB memory is assigned, starting from\n0x40000000 (1GB). Note that the host has 4KB as the base page size.\nIn the middile of migration, kvm_tlb_flush_vmid_range() is executed\nto flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to\n__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3\nand NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported\nby __TLBI_RANGE_NUM(). In this specific case, -1 has been returned\nfrom __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop\nin the __flush_tlb_range_op() until the variable @scale underflows\nand becomes -9, 0xffff708000040000 is set as the operand. The operand\nis wrong since it's sorted out by __TLBI_VADDR_RANGE() according to\ninvalid @scale and @num.\n\nFix it by extending __TLBI_RANGE_NUM() to support the combination of\nSCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can\nbe returned from the macro, meaning the TLBs for 0x200000 pages in the\nabove example can be flushed in one shoot with SCALE#3 and NUM#31. The\nmacro TLBI_RANGE_MASK is dropped since no one uses it any more. The\ncomments are also adjusted accordingly."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/arm64/include/asm/tlbflush.h"], "versions": [{"version": "117940aa6e5f8308f1529e1313660980f1dae771", "lessThan": "ac4ad513de4fba18b4ac0ace132777d0910e8cfa", "status": "affected", "versionType": "git"}, {"version": "117940aa6e5f8308f1529e1313660980f1dae771", "lessThan": "944db7b536baaf49d7e576af36a94f4719552b07", "status": "affected", "versionType": "git"}, {"version": "117940aa6e5f8308f1529e1313660980f1dae771", "lessThan": "e3ba51ab24fddef79fc212f9840de54db8fd1685", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/arm64/include/asm/tlbflush.h"], "versions": [{"version": "6.6", "status": "affected"}, {"version": "0", "lessThan": "6.6", "status": "unaffected", "versionType": "semver"}, {"version": "6.6.29", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.8.7", "lessThanOrEqual": "6.8.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.9", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa"}, {"url": "https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07"}, {"url": "https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685"}], "title": "arm64: tlb: Fix TLBI RANGE operand", "x_generator": {"engine": "bippy-5f407fcff5a0"}}, "adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-35980", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-05-20T17:01:18.086941Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-04T17:34:21.474Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-02T03:21:49.188Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685", "tags": ["x_transferred"]}]}]}}

{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2024-35980", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-05-17T13:50:33.144Z", "datePublished": "2024-05-20T09:42:05.085Z", "dateUpdated": "2024-06-04T17:34:21.474Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-05-29T05:32:21.802Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: tlb: Fix TLBI RANGE operand\n\nKVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty\npages are collected by VMM and the page table entries become write\nprotected during live migration. Unfortunately, the operand passed\nto the TLBI RANGE instruction isn't correctly sorted out due to the\ncommit 117940aa6e5f (\"KVM: arm64: Define kvm_tlb_flush_vmid_range()\").\nIt leads to crash on the destination VM after live migration because\nTLBs aren't flushed completely and some of the dirty pages are missed.\n\nFor example, I have a VM where 8GB memory is assigned, starting from\n0x40000000 (1GB). Note that the host has 4KB as the base page size.\nIn the middile of migration, kvm_tlb_flush_vmid_range() is executed\nto flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to\n__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3\nand NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported\nby __TLBI_RANGE_NUM(). In this specific case, -1 has been returned\nfrom __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop\nin the __flush_tlb_range_op() until the variable @scale underflows\nand becomes -9, 0xffff708000040000 is set as the operand. The operand\nis wrong since it's sorted out by __TLBI_VADDR_RANGE() according to\ninvalid @scale and @num.\n\nFix it by extending __TLBI_RANGE_NUM() to support the combination of\nSCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can\nbe returned from the macro, meaning the TLBs for 0x200000 pages in the\nabove example can be flushed in one shoot with SCALE#3 and NUM#31. The\nmacro TLBI_RANGE_MASK is dropped since no one uses it any more. The\ncomments are also adjusted accordingly."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/arm64/include/asm/tlbflush.h"], "versions": [{"version": "117940aa6e5f", "lessThan": "ac4ad513de4f", "status": "affected", "versionType": "git"}, {"version": "117940aa6e5f", "lessThan": "944db7b536ba", "status": "affected", "versionType": "git"}, {"version": "117940aa6e5f", "lessThan": "e3ba51ab24fd", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["arch/arm64/include/asm/tlbflush.h"], "versions": [{"version": "6.6", "status": "affected"}, {"version": "0", "lessThan": "6.6", "status": "unaffected", "versionType": "custom"}, {"version": "6.6.29", "lessThanOrEqual": "6.6.*", "status": "unaffected", "versionType": "custom"}, {"version": "6.8.7", "lessThanOrEqual": "6.8.*", "status": "unaffected", "versionType": "custom"}, {"version": "6.9", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa"}, {"url": "https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07"}, {"url": "https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685"}], "title": "arm64: tlb: Fix TLBI RANGE operand", "x_generator": {"engine": "bippy-a5840b7849dd"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2024-35980", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-05-20T17:01:18.086941Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-05-23T19:01:24.988Z"}, "title": "CISA ADP Vulnrichment"}]}}

{"descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: tlb: Fix TLBI RANGE operand\n\nKVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty\npages are collected by VMM and the page table entries become write\nprotected during live migration. Unfortunately, the operand passed\nto the TLBI RANGE instruction isn't correctly sorted out due to the\ncommit 117940aa6e5f (\"KVM: arm64: Define kvm_tlb_flush_vmid_range()\").\nIt leads to crash on the destination VM after live migration because\nTLBs aren't flushed completely and some of the dirty pages are missed.\n\nFor example, I have a VM where 8GB memory is assigned, starting from\n0x40000000 (1GB). Note that the host has 4KB as the base page size.\nIn the middile of migration, kvm_tlb_flush_vmid_range() is executed\nto flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to\n__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3\nand NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported\nby __TLBI_RANGE_NUM(). In this specific case, -1 has been returned\nfrom __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop\nin the __flush_tlb_range_op() until the variable @scale underflows\nand becomes -9, 0xffff708000040000 is set as the operand. The operand\nis wrong since it's sorted out by __TLBI_VADDR_RANGE() according to\ninvalid @scale and @num.\n\nFix it by extending __TLBI_RANGE_NUM() to support the combination of\nSCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can\nbe returned from the macro, meaning the TLBs for 0x200000 pages in the\nabove example can be flushed in one shoot with SCALE#3 and NUM#31. The\nmacro TLBI_RANGE_MASK is dropped since no one uses it any more. The\ncomments are also adjusted accordingly."}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: arm64: tlb: corrige el operando TLBI RANGE KVM/arm64 se basa en la funci\u00f3n TLBI RANGE para vaciar los TLB cuando VMM recopila las p\u00e1ginas sucias y las entradas de la tabla de p\u00e1ginas quedan protegidas contra escritura durante la migraci\u00f3n en vivo. . Desafortunadamente, el operando pasado a la instrucci\u00f3n TLBI RANGE no est\u00e1 ordenado correctamente debido a la confirmaci\u00f3n 117940aa6e5f (\"KVM: arm64: Define kvm_tlb_flush_vmid_range()\"). Esto provoca un bloqueo en la m\u00e1quina virtual de destino despu\u00e9s de la migraci\u00f3n en vivo porque los TLB no se vac\u00edan por completo y se omiten algunas de las p\u00e1ginas sucias. Por ejemplo, tengo una m\u00e1quina virtual a la que se asignan 8 GB de memoria, a partir de 0x40000000 (1 GB). Tenga en cuenta que el host tiene 4 KB como tama\u00f1o de p\u00e1gina base. En medio de la migraci\u00f3n, se ejecuta kvm_tlb_flush_vmid_range() para vaciar los TLB. Pasa MAX_TLBI_RANGE_PAGES como argumento para __kvm_tlb_flush_vmid_range() y __flush_s2_tlb_range_op(). SCALE#3 y NUM#31, correspondientes a MAX_TLBI_RANGE_PAGES, no son compatibles con __TLBI_RANGE_NUM(). En este caso espec\u00edfico, -1 ha sido devuelto por __TLBI_RANGE_NUM() para SCALE#3/2/1/0 y rechazado por el bucle en __flush_tlb_range_op() hasta que la variable @scale se desborda por debajo y se convierte en -9, 0xffff708000040000 se establece como el operando. El operando es incorrecto ya que __TLBI_VADDR_RANGE() lo ordena seg\u00fan @scale y @num no v\u00e1lidos. Solucionelo extendiendo __TLBI_RANGE_NUM() para admitir la combinaci\u00f3n de SCALE#3 y NUM#31. Con los cambios, [-1 31] en lugar de [-1 30] se puede devolver desde la macro, lo que significa que los TLB para p\u00e1ginas 0x200000 en el ejemplo anterior se pueden vaciar de una vez con ESCALA#3 y NUM#31. La macro TLBI_RANGE_MASK se elimina porque ya nadie la usa. Los comentarios tambi\u00e9n se adaptan en consecuencia."}], "id": "CVE-2024-35980", "lastModified": "2024-11-21T09:21:21.040", "metrics": {}, "published": "2024-05-20T10:15:12.550", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/944db7b536baaf49d7e576af36a94f4719552b07"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/ac4ad513de4fba18b4ac0ace132777d0910e8cfa"}, {"source": "af854a3a-2127-422b-91ae-364da2661108", "url": "https://git.kernel.org/stable/c/e3ba51ab24fddef79fc212f9840de54db8fd1685"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: arm64: tlb: Fix TLBI RANGE operand", "id": "2281870", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2281870"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "details": ["In the Linux kernel, the following vulnerability has been resolved:\narm64: tlb: Fix TLBI RANGE operand\nKVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty\npages are collected by VMM and the page table entries become write\nprotected during live migration. Unfortunately, the operand passed\nto the TLBI RANGE instruction isn't correctly sorted out due to the\ncommit 117940aa6e5f (\"KVM: arm64: Define kvm_tlb_flush_vmid_range()\").\nIt leads to crash on the destination VM after live migration because\nTLBs aren't flushed completely and some of the dirty pages are missed.\nFor example, I have a VM where 8GB memory is assigned, starting from\n0x40000000 (1GB). Note that the host has 4KB as the base page size.\nIn the middile of migration, kvm_tlb_flush_vmid_range() is executed\nto flush TLBs. It passes MAX_TLBI_RANGE_PAGES as the argument to\n__kvm_tlb_flush_vmid_range() and __flush_s2_tlb_range_op(). SCALE#3\nand NUM#31, corresponding to MAX_TLBI_RANGE_PAGES, isn't supported\nby __TLBI_RANGE_NUM(). In this specific case, -1 has been returned\nfrom __TLBI_RANGE_NUM() for SCALE#3/2/1/0 and rejected by the loop\nin the __flush_tlb_range_op() until the variable @scale underflows\nand becomes -9, 0xffff708000040000 is set as the operand. The operand\nis wrong since it's sorted out by __TLBI_VADDR_RANGE() according to\ninvalid @scale and @num.\nFix it by extending __TLBI_RANGE_NUM() to support the combination of\nSCALE#3 and NUM#31. With the changes, [-1 31] instead of [-1 30] can\nbe returned from the macro, meaning the TLBs for 0x200000 pages in the\nabove example can be flushed in one shoot with SCALE#3 and NUM#31. The\nmacro TLBI_RANGE_MASK is dropped since no one uses it any more. The\ncomments are also adjusted accordingly.", "A vulnerability affecting the Linux kernel on ARM64 systems, specifically in its KVM (Kernel-based Virtual Machine) module during live migration was found. An issue in the TLB (Translation Lookaside Buffer) invalidation process causes incomplete flushing of entries due to a miscalculated operand. This can lead to VM crashes on the destination host, as some memory changes are improperly handled."], "name": "CVE-2024-35980", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-05-20T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2024-35980\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-35980\nhttps://lore.kernel.org/linux-cve-announce/2024052026-CVE-2024-35980-7f0c@gregkh/T"], "threat_severity": "Moderate", "upstream_fix": "kernel 6.6.29, kernel 6.8.7, kernel 6.9"}