<?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>Fri, 02 Oct 2026 20:51:21 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-04347</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-04347</link>
      <description>bdu:2025-04347</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-04347</guid>
    </item>
    <item>
      <title>EUVD-2026-310289</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310289</link>
      <description>EUVD-2026-310289</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310289</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49004</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49004</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: Sync efi page table&amp;#39;s kernel mappings before switching&lt;/p&gt;
&lt;p&gt;The EFI page table is initially created as a copy of the kernel page table.
With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:
if the stack is allocated in a new PGD (one that was not present at the
moment of the efi page table creation or not synced in a previous vmalloc
fault), the kernel will take a trap when switching to the efi page table
when the vmalloc kernel stack is accessed, resulting in a kernel panic.&lt;/p&gt;
&lt;p&gt;Fix that by updating the efi kernel mappings before switching to the efi
page table.&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;riscv: Sync efi page table&amp;#39;s kernel mappings before switching&lt;/p&gt;
&lt;p&gt;The EFI page table is initially created as a copy of the kernel page table.
With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:
if the stack is allocated in a new PGD (one that was not present at the
moment of the efi page table creation or not synced in a previous vmalloc
fault), the kernel will take a trap when switching to the efi page table
when the vmalloc kernel stack is accessed, resulting in a kernel panic.&lt;/p&gt;
&lt;p&gt;Fix that by updating the efi kernel mappings before switching to the efi
page table.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49004</guid>
    </item>
    <item>
      <title>GHSA-f43m-69ch-cggg</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-f43m-69ch-cggg</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;riscv: Sync efi page table&amp;#39;s kernel mappings before switching&lt;/p&gt;
&lt;p&gt;The EFI page table is initially created as a copy of the kernel page table.
With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:
if the stack is allocated in a new PGD (one that was not present at the
moment of the efi page table creation or not synced in a previous vmalloc
fault), the kernel will take a trap when switching to the efi page table
when the vmalloc kernel stack is accessed, resulting in a kernel panic.&lt;/p&gt;
&lt;p&gt;Fix that by updating the efi kernel mappings before switching to the efi
page table.&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;riscv: Sync efi page table&amp;#39;s kernel mappings before switching&lt;/p&gt;
&lt;p&gt;The EFI page table is initially created as a copy of the kernel page table.
With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area:
if the stack is allocated in a new PGD (one that was not present at the
moment of the efi page table creation or not synced in a previous vmalloc
fault), the kernel will take a trap when switching to the efi page table
when the vmalloc kernel stack is accessed, resulting in a kernel panic.&lt;/p&gt;
&lt;p&gt;Fix that by updating the efi kernel mappings before switching to the efi
page table.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-f43m-69ch-cggg</guid>
    </item>
    <item>
      <title>OESA-2024-2368 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-2368</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.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:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm &amp;amp;quot;python3&amp;amp;quot;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_ad…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.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:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm &amp;amp;quot;python3&amp;amp;quot;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_ad…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-2368</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49004</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49004</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 92 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: riscv: Sync efi page table&amp;#39;s kernel mappings before switching The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic. Fix that by updating the efi kernel mappings before switching to the efi page table.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 92 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: riscv: Sync efi page table&amp;#39;s kernel mappings before switching The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic. Fix that by updating the efi kernel mappings before switching to the efi page table.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49004</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-3251 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht näher bekannte Auswirkungen zu erzielen..&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-3251</guid>
    </item>
  </channel>
</rss>
