https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 07 Oct 2026 20:31:45 +0000 https://cve.radiocsirt.org/vuln/bdu:2025-03072 bdu:2025-03072 https://cve.radiocsirt.org/vuln/bdu:2025-03072 https://cve.radiocsirt.org/vuln/bell-cve-2024-35980 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-35980 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0611 certfr-2024-avi-0611 https://cve.radiocsirt.org/vuln/certfr-2024-avi-0611 https://cve.radiocsirt.org/vuln/euvd-2026-345731 EUVD-2026-345731 https://cve.radiocsirt.org/vuln/euvd-2026-345731 https://cve.radiocsirt.org/vuln/fkie_cve-2024-35980 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arm64: tlb: Fix TLBI RANGE operand</p> <p>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&#39;t correctly sorted out due to the commit 117940aa6e5f (&#34;KVM: arm64: Define kvm_tlb_flush_vmid_range()&#34;). It leads to crash on the destination VM after live migration because TLBs aren&#39;t flushed completely and some of the dirty pages are missed.</p> <p>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&#39;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&#39;s sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num.</p> <p>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 r…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arm64: tlb: Fix TLBI RANGE operand</p> <p>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&#39;t correctly sorted out due to the commit 117940aa6e5f (&#34;KVM: arm64: Define kvm_tlb_flush_vmid_range()&#34;). It leads to crash on the destination VM after live migration because TLBs aren&#39;t flushed completely and some of the dirty pages are missed.</p> <p>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&#39;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&#39;s sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num.</p> <p>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 r…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-35980 https://cve.radiocsirt.org/vuln/ghsa-xv8c-x88j-w3qj <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arm64: tlb: Fix TLBI RANGE operand</p> <p>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&#39;t correctly sorted out due to the commit 117940aa6e5f (&#34;KVM: arm64: Define kvm_tlb_flush_vmid_range()&#34;). It leads to crash on the destination VM after live migration because TLBs aren&#39;t flushed completely and some of the dirty pages are missed.</p> <p>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&#39;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&#39;s sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num.</p> <p>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 r…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>arm64: tlb: Fix TLBI RANGE operand</p> <p>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&#39;t correctly sorted out due to the commit 117940aa6e5f (&#34;KVM: arm64: Define kvm_tlb_flush_vmid_range()&#34;). It leads to crash on the destination VM after live migration because TLBs aren&#39;t flushed completely and some of the dirty pages are missed.</p> <p>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&#39;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&#39;s sorted out by __TLBI_VADDR_RANGE() according to invalid @scale and @num.</p> <p>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 r…</p> https://cve.radiocsirt.org/vuln/ghsa-xv8c-x88j-w3qj https://cve.radiocsirt.org/vuln/suse-su-2024:3984-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2024:3984-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35980 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 74 more</p> <p>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&#39;t correctly sorted out due to the commit 117940aa6e5f (&#34;KVM: arm64: Define kvm_tlb_flush_vmid_range()&#34;). It leads to crash on the destination VM after live migration because TLBs aren&#39;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&#39;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&#39;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 retur…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 74 more</p> <p>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&#39;t correctly sorted out due to the commit 117940aa6e5f (&#34;KVM: arm64: Define kvm_tlb_flush_vmid_range()&#34;). It leads to crash on the destination VM after live migration because TLBs aren&#39;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&#39;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&#39;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 retur…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-35980 https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188 <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> <p>Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1188