<?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 19:53:09 +0000</lastBuildDate>
    <item>
      <title>bdu:2025-14382</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2025-14382</link>
      <description>bdu:2025-14382</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2025-14382</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-309731</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-309731</link>
      <description>EUVD-2026-309731</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-309731</guid>
    </item>
    <item>
      <title>fkie_cve-2021-47424</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2021-47424</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;i40e: Fix freeing of uninitialized misc IRQ vector&lt;/p&gt;
&lt;p&gt;When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:&lt;/p&gt;
&lt;p&gt;Trying to free already-free IRQ 266
   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
   Workqueue: events work_for_cpu_fn
   RIP: 0010:__free_irq+0x9a/0x300
   Call Trace:
   ? synchronize_irq+0x3a/0xa0
   free_irq+0x2e/0x60
   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
   i40e_probe.part.108+0x134b/0x1a40 [i40e]
   ? kmem_cache_alloc+0x158/0x1c0
   ? acpi_ut_update_ref_count.part.1+0x8e/0x345
   ? acpi_ut_update_object_reference+0x15e/0x1e2
   ? strstr+0x21/0x70
   ? irq_get_irq_data+0xa/0x20
   ? mp_check_pin_attr+0x13/0xc0
   ? irq_get_irq_data+0xa/0x20
   ? mp_map_pin_to_irq+0xd3/0x2f0
   ? acpi_register_gsi_ioapic+0x93/0x170
   ? pci_conf1_read+0xa4/0x100
   ? pci_bus_read_config_word+0x49/0x70
   ? do_pci_enable_device+0xcc/0x100
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x112/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40&lt;/p&gt;
&lt;p&gt;The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.&lt;/p&gt;
&lt;p&gt;Add a check in i40e_clear_interrupt_…&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;i40e: Fix freeing of uninitialized misc IRQ vector&lt;/p&gt;
&lt;p&gt;When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:&lt;/p&gt;
&lt;p&gt;Trying to free already-free IRQ 266
   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
   Workqueue: events work_for_cpu_fn
   RIP: 0010:__free_irq+0x9a/0x300
   Call Trace:
   ? synchronize_irq+0x3a/0xa0
   free_irq+0x2e/0x60
   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
   i40e_probe.part.108+0x134b/0x1a40 [i40e]
   ? kmem_cache_alloc+0x158/0x1c0
   ? acpi_ut_update_ref_count.part.1+0x8e/0x345
   ? acpi_ut_update_object_reference+0x15e/0x1e2
   ? strstr+0x21/0x70
   ? irq_get_irq_data+0xa/0x20
   ? mp_check_pin_attr+0x13/0xc0
   ? irq_get_irq_data+0xa/0x20
   ? mp_map_pin_to_irq+0xd3/0x2f0
   ? acpi_register_gsi_ioapic+0x93/0x170
   ? pci_conf1_read+0xa4/0x100
   ? pci_bus_read_config_word+0x49/0x70
   ? do_pci_enable_device+0xcc/0x100
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x112/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40&lt;/p&gt;
&lt;p&gt;The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.&lt;/p&gt;
&lt;p&gt;Add a check in i40e_clear_interrupt_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2021-47424</guid>
    </item>
    <item>
      <title>GHSA-hf7w-m8fc-q8fp</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hf7w-m8fc-q8fp</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;i40e: Fix freeing of uninitialized misc IRQ vector&lt;/p&gt;
&lt;p&gt;When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:&lt;/p&gt;
&lt;p&gt;Trying to free already-free IRQ 266
   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
   Workqueue: events work_for_cpu_fn
   RIP: 0010:__free_irq+0x9a/0x300
   Call Trace:
   ? synchronize_irq+0x3a/0xa0
   free_irq+0x2e/0x60
   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
   i40e_probe.part.108+0x134b/0x1a40 [i40e]
   ? kmem_cache_alloc+0x158/0x1c0
   ? acpi_ut_update_ref_count.part.1+0x8e/0x345
   ? acpi_ut_update_object_reference+0x15e/0x1e2
   ? strstr+0x21/0x70
   ? irq_get_irq_data+0xa/0x20
   ? mp_check_pin_attr+0x13/0xc0
   ? irq_get_irq_data+0xa/0x20
   ? mp_map_pin_to_irq+0xd3/0x2f0
   ? acpi_register_gsi_ioapic+0x93/0x170
   ? pci_conf1_read+0xa4/0x100
   ? pci_bus_read_config_word+0x49/0x70
   ? do_pci_enable_device+0xcc/0x100
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x112/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40&lt;/p&gt;
&lt;p&gt;The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.&lt;/p&gt;
&lt;p&gt;Add a check in i40e_clear_interrupt_…&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;i40e: Fix freeing of uninitialized misc IRQ vector&lt;/p&gt;
&lt;p&gt;When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:&lt;/p&gt;
&lt;p&gt;Trying to free already-free IRQ 266
   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
   Workqueue: events work_for_cpu_fn
   RIP: 0010:__free_irq+0x9a/0x300
   Call Trace:
   ? synchronize_irq+0x3a/0xa0
   free_irq+0x2e/0x60
   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
   i40e_probe.part.108+0x134b/0x1a40 [i40e]
   ? kmem_cache_alloc+0x158/0x1c0
   ? acpi_ut_update_ref_count.part.1+0x8e/0x345
   ? acpi_ut_update_object_reference+0x15e/0x1e2
   ? strstr+0x21/0x70
   ? irq_get_irq_data+0xa/0x20
   ? mp_check_pin_attr+0x13/0xc0
   ? irq_get_irq_data+0xa/0x20
   ? mp_map_pin_to_irq+0xd3/0x2f0
   ? acpi_register_gsi_ioapic+0x93/0x170
   ? pci_conf1_read+0xa4/0x100
   ? pci_bus_read_config_word+0x49/0x70
   ? do_pci_enable_device+0xcc/0x100
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x112/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40&lt;/p&gt;
&lt;p&gt;The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.&lt;/p&gt;
&lt;p&gt;Add a check in i40e_clear_interrupt_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hf7w-m8fc-q8fp</guid>
    </item>
    <item>
      <title>OESA-2024-1705 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1705</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: cdc_eem: fix tx fixup skb leak&#13;
&#13;
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
if skb_copy_expand() failed, it return NULL,
usbnet_start_xmit() will have no chance to free original skb.&#13;
&#13;
fix it by free orginal skb in eem_tx_fixup() first,
then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
gfs2: Fix use-after-free in gfs2_glock_shrink_scan&#13;
&#13;
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().&#13;
&#13;
On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&amp;amp;amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.&#13;
&#13;
Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;amp;amp;lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.(CVE-2021-47254)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netrom: Decrease sock refcount when sock timers expire&#13;
&#13;
Commit 63346650c1a9 (&amp;amp;quot;netrom: switch to sock timer API&amp;amp;quot;) switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().&#13;
&#13;
Function sk_reset_t…&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: cdc_eem: fix tx fixup skb leak&#13;
&#13;
when usbnet transmit a skb, eem fixup it in eem_tx_fixup(),
if skb_copy_expand() failed, it return NULL,
usbnet_start_xmit() will have no chance to free original skb.&#13;
&#13;
fix it by free orginal skb in eem_tx_fixup() first,
then check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
gfs2: Fix use-after-free in gfs2_glock_shrink_scan&#13;
&#13;
The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to
remove the glock from the lru list in __gfs2_glock_put().&#13;
&#13;
On the shrink scan path, the same flag is cleared under lru_lock but because
of cond_resched_lock(&amp;amp;amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the
put side can be made without deleting the glock from the lru list.&#13;
&#13;
Keep GLF_LRU across the race window opened by cond_resched_lock(&amp;amp;amp;lru_lock) to
ensure correct behavior on both sides - clear GLF_LRU after list_del under
lru_lock.(CVE-2021-47254)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
netrom: Decrease sock refcount when sock timers expire&#13;
&#13;
Commit 63346650c1a9 (&amp;amp;quot;netrom: switch to sock timer API&amp;amp;quot;) switched to use
sock timer API. It replaces mod_timer() by sk_reset_timer(), and
del_timer() by sk_stop_timer().&#13;
&#13;
Function sk_reset_t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1705</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-47424</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47424</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: linux-azure, 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:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 101 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: i40e: Fix freeing of uninitialized misc IRQ vector When VSI set up failed in i40e_probe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40e_clear_interrupt_scheme and produced a kernel Oops:    Trying to free already-free IRQ 266    WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300    Workqueue: events work_for_cpu_fn    RIP: 0010:__free_irq+0x9a/0x300    Call Trace:    ? synchronize_irq+0x3a/0xa0    free_irq+0x2e/0x60    i40e_clear_interrupt_scheme+0x53/0x190 [i40e]    i40e_probe.part.108+0x134b/0x1a40 [i40e]    ? kmem_cache_alloc+0x158/0x1c0    ? acpi_ut_update_ref_count.part.1+0x8e/0x345    ? acpi_ut_update_object_reference+0x15e/0x1e2    ? strstr+0x21/0x70    ? irq_get_irq_data+0xa/0x20    ? mp_check_pin_attr+0x13/0xc0    ? irq_get_irq_data+0xa/0x20    ? mp_map_pin_to_irq+0xd3/0x2f0    ? acpi_register_gsi_ioapic+0x93/0x170    ? pci_conf1_read+0xa4/0x100    ? pci_bus_read_config_word+0x49/0x70    ? do_pci_enable_device+0xcc/0x100    local_pci_probe+0x41/0x90    work_for_cpu_fn+0x16/0x20    process_one_work+0x1a7/0x360    worker_thread+0x1cf/0x390    ? create_worker+0x1a0/0x1a0    kthread+0x112/0x130    ? kthread_flush_work_fn+0x10/0x10    ret_from_fork+0x1f/0x40 The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors. Add a check in i40e_clear_interrupt_schem…&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: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:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 101 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: i40e: Fix freeing of uninitialized misc IRQ vector When VSI set up failed in i40e_probe() as part of PF switch set up driver was trying to free misc IRQ vectors in i40e_clear_interrupt_scheme and produced a kernel Oops:    Trying to free already-free IRQ 266    WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300    Workqueue: events work_for_cpu_fn    RIP: 0010:__free_irq+0x9a/0x300    Call Trace:    ? synchronize_irq+0x3a/0xa0    free_irq+0x2e/0x60    i40e_clear_interrupt_scheme+0x53/0x190 [i40e]    i40e_probe.part.108+0x134b/0x1a40 [i40e]    ? kmem_cache_alloc+0x158/0x1c0    ? acpi_ut_update_ref_count.part.1+0x8e/0x345    ? acpi_ut_update_object_reference+0x15e/0x1e2    ? strstr+0x21/0x70    ? irq_get_irq_data+0xa/0x20    ? mp_check_pin_attr+0x13/0xc0    ? irq_get_irq_data+0xa/0x20    ? mp_map_pin_to_irq+0xd3/0x2f0    ? acpi_register_gsi_ioapic+0x93/0x170    ? pci_conf1_read+0xa4/0x100    ? pci_bus_read_config_word+0x49/0x70    ? do_pci_enable_device+0xcc/0x100    local_pci_probe+0x41/0x90    work_for_cpu_fn+0x16/0x20    process_one_work+0x1a7/0x360    worker_thread+0x1cf/0x390    ? create_worker+0x1a0/0x1a0    kthread+0x112/0x130    ? kthread_flush_work_fn+0x10/0x10    ret_from_fork+0x1f/0x40 The problem is that at that point misc IRQ vectors were not allocated yet and we get a call trace that driver is trying to free already free IRQ vectors. Add a check in i40e_clear_interrupt_schem…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2021-47424</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1197 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service und unspezifische Angriffe</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1197</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder unspezifische Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder unspezifische Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1197</guid>
    </item>
  </channel>
</rss>
