<?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 23:12:44 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-05784</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-05784</link>
      <description>bdu:2026-05784</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-05784</guid>
    </item>
    <item>
      <title>EUVD-2026-311056</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-311056</link>
      <description>EUVD-2026-311056</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-311056</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50159</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-50159</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds&lt;/p&gt;
&lt;p&gt;Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:&lt;/p&gt;
&lt;p&gt;$ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39;&lt;/p&gt;
&lt;p&gt;&amp;lt;snip&amp;gt;
 BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
 Faulting instruction address: 0xc000000000837974
 Oops: Kernel access of bad area, sig: 11 [#1]
&amp;lt;snip&amp;gt;
 NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 Call Trace:
 [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
 [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
 Instruction dump:
 f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
 7c0802a6 fb610198 7c9b2378 f80101d0 &amp;lt;a1240000&amp;gt; 2c090001 40820614 e9240010
 ---[ end trace 00000000000…&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;of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds&lt;/p&gt;
&lt;p&gt;Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:&lt;/p&gt;
&lt;p&gt;$ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39;&lt;/p&gt;
&lt;p&gt;&amp;lt;snip&amp;gt;
 BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
 Faulting instruction address: 0xc000000000837974
 Oops: Kernel access of bad area, sig: 11 [#1]
&amp;lt;snip&amp;gt;
 NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 Call Trace:
 [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
 [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
 Instruction dump:
 f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
 7c0802a6 fb610198 7c9b2378 f80101d0 &amp;lt;a1240000&amp;gt; 2c090001 40820614 e9240010
 ---[ end trace 00000000000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-50159</guid>
    </item>
    <item>
      <title>GHSA-gjjr-vrfh-q64m</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gjjr-vrfh-q64m</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds&lt;/p&gt;
&lt;p&gt;Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:&lt;/p&gt;
&lt;p&gt;$ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39;&lt;/p&gt;
&lt;p&gt;&amp;lt;snip&amp;gt;
 BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
 Faulting instruction address: 0xc000000000837974
 Oops: Kernel access of bad area, sig: 11 [#1]
&amp;lt;snip&amp;gt;
 NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 Call Trace:
 [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
 [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
 Instruction dump:
 f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
 7c0802a6 fb610198 7c9b2378 f80101d0 &amp;lt;a1240000&amp;gt; 2c090001 40820614 e9240010
 ---[ end trace 00000000000…&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;of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds&lt;/p&gt;
&lt;p&gt;Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s
ima-kexec-buffer lies outside the addressable memory range. This can result
in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the
ima-kexec-buffer was allocated beyond that range by the previous kernel.
The panic is usually of the form below:&lt;/p&gt;
&lt;p&gt;$ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39;&lt;/p&gt;
&lt;p&gt;&amp;lt;snip&amp;gt;
 BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000
 Faulting instruction address: 0xc000000000837974
 Oops: Kernel access of bad area, sig: 11 [#1]
&amp;lt;snip&amp;gt;
 NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0
 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 Call Trace:
 [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160
 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108
 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120
 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0
 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec
 [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0
 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64
 Instruction dump:
 f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330
 7c0802a6 fb610198 7c9b2378 f80101d0 &amp;lt;a1240000&amp;gt; 2c090001 40820614 e9240010
 ---[ end trace 00000000000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gjjr-vrfh-q64m</guid>
    </item>
    <item>
      <title>OESA-2026-1341 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1341</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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource().  And it s required to release the resource usingfree_resource().  Howerver, many people use kfree directly which willresult in kernel BUG.  In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below:   (Thread 1)                  |      (Thread 2)                               | _set_timer()rtw_surveydone_event_callback()|  mod_timer() spin_lock_bh() //(1)          |  (wait a time) ...                           | rtw_scan_timeout_handler() del_timer_sync()              |  spin_lock_bh() //(2) (wait timer to stop)          |  ...We hold pmlmepriv-&amp;amp;gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-&amp;amp;gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obta…&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):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource().  And it s required to release the resource usingfree_resource().  Howerver, many people use kfree directly which willresult in kernel BUG.  In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below:   (Thread 1)                  |      (Thread 2)                               | _set_timer()rtw_surveydone_event_callback()|  mod_timer() spin_lock_bh() //(1)          |  (wait a time) ...                           | rtw_scan_timeout_handler() del_timer_sync()              |  spin_lock_bh() //(2) (wait timer to stop)          |  ...We hold pmlmepriv-&amp;amp;gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-&amp;amp;gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obta…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1341</guid>
    </item>
    <item>
      <title>RHSA-2025:6966 — Red Hat Security Advisory: kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2025:6966</link>
      <description>&lt;p&gt;kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2025:6966</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50159</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50159</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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below: $ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39; &amp;lt;snip&amp;gt;  BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000  Faulting instruction address: 0xc000000000837974  Oops: Kernel access of bad area, sig: 11 [#1] &amp;lt;snip&amp;gt;  NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0  LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160  Call Trace:  [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160  [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108  [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120  [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0  [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec  [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0  [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64  Instruction dump:  f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330  7c0802a6 fb610198 7c9b2378 f80101d0 &amp;lt;a1240000&amp;gt; 2c090001 40820614 e9240010  ---[ end trace 000000000000000…&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:16.04:LTS: linux-hwe-edge, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:18.04:LTS: linux, Ubuntu:Pro:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.0 and 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: of: check previous kernel&amp;#39;s ima-kexec-buffer against memory bounds Presently ima_get_kexec_buffer() doesn&amp;#39;t check if the previous kernel&amp;#39;s ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with &amp;#39;mem=X&amp;#39; arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below: $ sudo kexec --initrd initrd vmlinux --append=&amp;#39;mem=16G&amp;#39; &amp;lt;snip&amp;gt;  BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000  Faulting instruction address: 0xc000000000837974  Oops: Kernel access of bad area, sig: 11 [#1] &amp;lt;snip&amp;gt;  NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0  LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160  Call Trace:  [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160  [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108  [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120  [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0  [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec  [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0  [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64  Instruction dump:  f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330  7c0802a6 fb610198 7c9b2378 f80101d0 &amp;lt;a1240000&amp;gt; 2c090001 40820614 e9240010  ---[ end trace 000000000000000…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50159</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-1350 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1350</guid>
    </item>
  </channel>
</rss>
