<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 10:37:18 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14604</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-14604</link>
      <description>bdu:2025-14604</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-14604</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0496 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</link>
      <description>certfr-2024-avi-0496</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0496</guid>
    </item>
    <item>
      <title>EUVD-2026-309638</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309638</link>
      <description>EUVD-2026-309638</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309638</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47277</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47277</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kvm: avoid speculation-based attacks from out-of-range memslot accesses&lt;/p&gt;
&lt;p&gt;KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:&lt;/p&gt;
&lt;p&gt;hva = slot-&amp;gt;userspace_addr + (gfn - slot-&amp;gt;base_gfn) * PAGE_SIZE&lt;/p&gt;
&lt;p&gt;It is expected that gfn falls within the boundaries of the guest&amp;#39;s
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.&lt;/p&gt;
&lt;p&gt;__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest&amp;#39;s
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.&lt;/p&gt;
&lt;p&gt;Right now it&amp;#39;s not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kvm: avoid speculation-based attacks from out-of-range memslot accesses&lt;/p&gt;
&lt;p&gt;KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:&lt;/p&gt;
&lt;p&gt;hva = slot-&amp;gt;userspace_addr + (gfn - slot-&amp;gt;base_gfn) * PAGE_SIZE&lt;/p&gt;
&lt;p&gt;It is expected that gfn falls within the boundaries of the guest&amp;#39;s
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.&lt;/p&gt;
&lt;p&gt;__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest&amp;#39;s
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.&lt;/p&gt;
&lt;p&gt;Right now it&amp;#39;s not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47277</guid>
    </item>
    <item>
      <title>GHSA-6239-6f98-f8vf</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-6239-6f98-f8vf</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kvm: avoid speculation-based attacks from out-of-range memslot accesses&lt;/p&gt;
&lt;p&gt;KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:&lt;/p&gt;
&lt;p&gt;hva = slot-&amp;gt;userspace_addr + (gfn - slot-&amp;gt;base_gfn) * PAGE_SIZE&lt;/p&gt;
&lt;p&gt;It is expected that gfn falls within the boundaries of the guest&amp;#39;s
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.&lt;/p&gt;
&lt;p&gt;__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest&amp;#39;s
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.&lt;/p&gt;
&lt;p&gt;Right now it&amp;#39;s not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kvm: avoid speculation-based attacks from out-of-range memslot accesses&lt;/p&gt;
&lt;p&gt;KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical
address (gpa) to a host virtual address using the right-shifted gpa
(also known as gfn) and a struct kvm_memory_slot.  The translation is
performed in __gfn_to_hva_memslot using the following formula:&lt;/p&gt;
&lt;p&gt;hva = slot-&amp;gt;userspace_addr + (gfn - slot-&amp;gt;base_gfn) * PAGE_SIZE&lt;/p&gt;
&lt;p&gt;It is expected that gfn falls within the boundaries of the guest&amp;#39;s
physical memory.  However, a guest can access invalid physical addresses
in such a way that the gfn is invalid.&lt;/p&gt;
&lt;p&gt;__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first
retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot
does check that the gfn falls within the boundaries of the guest&amp;#39;s
physical memory or not, a CPU can speculate the result of the check and
continue execution speculatively using an illegal gfn. The speculation
can result in calculating an out-of-bounds hva.  If the resulting host
virtual address is used to load another guest physical address, this
is effectively a Spectre gadget consisting of two consecutive reads,
the second of which is data dependent on the first.&lt;/p&gt;
&lt;p&gt;Right now it&amp;#39;s not clear if there are any cases in which this is
exploitable.  One interesting case was reported by the original author
of this patch, and involves visiting guest page tables on x86.  Right
now these a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-6239-6f98-f8vf</guid>
    </item>
    <item>
      <title>OESA-2024-1692 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1692</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
net: usb: fix possible use-after-free in smsc75xx_bind&#13;
&#13;
The commit 46a8b29c6306 (&amp;amp;quot;net: usb: fix memory leak in smsc75xx_bind&amp;amp;quot;)
fails to clean up the work scheduled in smsc75xx_reset-&amp;amp;gt;
smsc75xx_set_multicast, which leads to use-after-free if the work is
scheduled to start after the deallocation. In addition, this patch
also removes a dangling pointer - dev-&amp;amp;gt;data[0].&#13;
&#13;
This patch calls cancel_work_sync to cancel the scheduled work and set
the dangling pointer to NULL.(CVE-2021-47239)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
RDMA: Verify port when creating flow rule&#13;
&#13;
Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.&#13;
&#13;
Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:20.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
net: usb: fix possible use-after-free in smsc75xx_bind&#13;
&#13;
The commit 46a8b29c6306 (&amp;amp;quot;net: usb: fix memory leak in smsc75xx_bind&amp;amp;quot;)
fails to clean up the work scheduled in smsc75xx_reset-&amp;amp;gt;
smsc75xx_set_multicast, which leads to use-after-free if the work is
scheduled to start after the deallocation. In addition, this patch
also removes a dangling pointer - dev-&amp;amp;gt;data[0].&#13;
&#13;
This patch calls cancel_work_sync to cancel the scheduled work and set
the dangling pointer to NULL.(CVE-2021-47239)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
RDMA: Verify port when creating flow rule&#13;
&#13;
Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.&#13;
&#13;
Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)(CVE-2021-47…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1692</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:1979-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:1979-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:1979-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2021-47277</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47277</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 108 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot.  The translation is performed in __gfn_to_hva_memslot using the following formula:       hva = slot-&amp;gt;userspace_addr + (gfn - slot-&amp;gt;base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest&amp;#39;s physical memory.  However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest&amp;#39;s physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva.  If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it&amp;#39;s not clear if there are any cases in which this is exploitable.  One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86.  Right now these are not…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 108 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: kvm: avoid speculation-based attacks from out-of-range memslot accesses KVM&amp;#39;s mechanism for accessing guest memory translates a guest physical address (gpa) to a host virtual address using the right-shifted gpa (also known as gfn) and a struct kvm_memory_slot.  The translation is performed in __gfn_to_hva_memslot using the following formula:       hva = slot-&amp;gt;userspace_addr + (gfn - slot-&amp;gt;base_gfn) * PAGE_SIZE It is expected that gfn falls within the boundaries of the guest&amp;#39;s physical memory.  However, a guest can access invalid physical addresses in such a way that the gfn is invalid. __gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first retrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot does check that the gfn falls within the boundaries of the guest&amp;#39;s physical memory or not, a CPU can speculate the result of the check and continue execution speculatively using an illegal gfn. The speculation can result in calculating an out-of-bounds hva.  If the resulting host virtual address is used to load another guest physical address, this is effectively a Spectre gadget consisting of two consecutive reads, the second of which is data dependent on the first. Right now it&amp;#39;s not clear if there are any cases in which this is exploitable.  One interesting case was reported by the original author of this patch, and involves visiting guest page tables on x86.  Right now these are not…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47277</guid>
    </item>
  </channel>
</rss>
