<?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 12:09:49 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-02037</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-02037</link>
      <description>bdu:2026-02037</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-02037</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0316 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0316</link>
      <description>certfr-2026-avi-0316</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0316</guid>
    </item>
    <item>
      <title>EUVD-2026-323448</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-323448</link>
      <description>EUVD-2026-323448</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-323448</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49961</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49961</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&lt;/p&gt;
&lt;p&gt;Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg-&amp;gt;precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.&lt;/p&gt;
&lt;p&gt;To show a concrete example of the problem:&lt;/p&gt;
&lt;p&gt;0000000000000000 &amp;lt;prog&amp;gt;:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 &amp;gt; r2 goto +18 &amp;lt;LBB5_5&amp;gt;
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 &amp;lt;LBB5_3&amp;gt;
      10:       r2 = -1&lt;/p&gt;
&lt;p&gt;0000000000000058 &amp;lt;LBB5_3&amp;gt;:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 &amp;lt;LBB5_5&amp;gt;
      16:       r1 = r0
      17:       r1 += 16777215
      18:       w2 = 0
      19:       *(u8…&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;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&lt;/p&gt;
&lt;p&gt;Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg-&amp;gt;precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.&lt;/p&gt;
&lt;p&gt;To show a concrete example of the problem:&lt;/p&gt;
&lt;p&gt;0000000000000000 &amp;lt;prog&amp;gt;:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 &amp;gt; r2 goto +18 &amp;lt;LBB5_5&amp;gt;
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 &amp;lt;LBB5_3&amp;gt;
      10:       r2 = -1&lt;/p&gt;
&lt;p&gt;0000000000000058 &amp;lt;LBB5_3&amp;gt;:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 &amp;lt;LBB5_5&amp;gt;
      16:       r1 = r0
      17:       r1 += 16777215
      18:       w2 = 0
      19:       *(u8…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49961</guid>
    </item>
    <item>
      <title>GHSA-34r5-4vr6-q5h6</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-34r5-4vr6-q5h6</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&lt;/p&gt;
&lt;p&gt;Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg-&amp;gt;precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.&lt;/p&gt;
&lt;p&gt;To show a concrete example of the problem:&lt;/p&gt;
&lt;p&gt;0000000000000000 &amp;lt;prog&amp;gt;:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 &amp;gt; r2 goto +18 &amp;lt;LBB5_5&amp;gt;
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 &amp;lt;LBB5_3&amp;gt;
      10:       r2 = -1&lt;/p&gt;
&lt;p&gt;0000000000000058 &amp;lt;LBB5_3&amp;gt;:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 &amp;lt;LBB5_5&amp;gt;
      16:       r1 = r0
      17:       r1 += 16777215
      18:       w2 = 0
      19:       *(u8…&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;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&lt;/p&gt;
&lt;p&gt;Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg-&amp;gt;precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.&lt;/p&gt;
&lt;p&gt;To show a concrete example of the problem:&lt;/p&gt;
&lt;p&gt;0000000000000000 &amp;lt;prog&amp;gt;:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 &amp;gt; r2 goto +18 &amp;lt;LBB5_5&amp;gt;
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 &amp;lt;LBB5_3&amp;gt;
      10:       r2 = -1&lt;/p&gt;
&lt;p&gt;0000000000000058 &amp;lt;LBB5_3&amp;gt;:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 &amp;lt;LBB5_5&amp;gt;
      16:       r1 = r0
      17:       r1 += 16777215
      18:       w2 = 0
      19:       *(u8…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-34r5-4vr6-q5h6</guid>
    </item>
    <item>
      <title>msrc_CVE-2022-49961 — bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2022-49961</link>
      <description>msrc_CVE-2022-49961</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2022-49961</guid>
    </item>
    <item>
      <title>OESA-2025-1876 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-1876</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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:&lt;/p&gt;
&lt;p&gt;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&lt;/p&gt;
&lt;p&gt;Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg-&amp;amp;gt;precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.&lt;/p&gt;
&lt;p&gt;To show a concrete example of the problem:&lt;/p&gt;
&lt;p&gt;0000000000000000 &amp;amp;lt;prog&amp;amp;gt;:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 &amp;amp;gt; r2 goto +18 &amp;amp;lt;LBB5_5&amp;amp;gt;
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 &amp;amp;lt;LBB5_3&amp;amp;gt;
      10:       r2 = -1&lt;/p&gt;
&lt;p&gt;0000000000000058 &amp;amp;lt;LBB5_3&amp;amp;gt;:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 &amp;amp;lt…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP3: 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:&lt;/p&gt;
&lt;p&gt;bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO&lt;/p&gt;
&lt;p&gt;Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg-&amp;amp;gt;precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.&lt;/p&gt;
&lt;p&gt;To show a concrete example of the problem:&lt;/p&gt;
&lt;p&gt;0000000000000000 &amp;amp;lt;prog&amp;amp;gt;:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 &amp;amp;gt; r2 goto +18 &amp;amp;lt;LBB5_5&amp;amp;gt;
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 &amp;amp;lt;LBB5_3&amp;amp;gt;
      10:       r2 = -1&lt;/p&gt;
&lt;p&gt;0000000000000058 &amp;amp;lt;LBB5_3&amp;amp;gt;:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 &amp;amp;lt…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-1876</guid>
    </item>
    <item>
      <title>RHSA-2023:2458 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2023:2458</link>
      <description>&lt;p&gt;hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: data races around icsk-&amp;gt;icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk-&amp;gt;sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink relo…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: data races around icsk-&amp;gt;icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk-&amp;gt;sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink relo…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2023:2458</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49961</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49961</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 110 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg-&amp;gt;precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 &amp;lt;prog&amp;gt;:        0:       r2 = *(u32 *)(r1 + 80)        1:       r1 = *(u32 *)(r1 + 76)        2:       r3 = r1        3:       r3 += 4        4:       if r3 &amp;gt; r2 goto +18 &amp;lt;LBB5_5&amp;gt;        5:       w2 = 0        6:       *(u32 *)(r1 + 0) = r2        7:       r1 = *(u32 *)(r1 + 0)        8:       r2 = 1        9:       if w1 == 0 goto +1 &amp;lt;LBB5_3&amp;gt;       10:       r2 = -1 0000000000000058 &amp;lt;LBB5_3&amp;gt;:       11:       r1 = 0 ll       13:       r3 = 0       14:       call bpf_ringbuf_reserve       15:       if r0 == 0 goto +7 &amp;lt;LBB5_5&amp;gt;       16:       r1 = r0       17:       r1 += 16777215       18:       w2 = 0       19:       *(u8 *)(r…&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 110 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg-&amp;gt;precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 &amp;lt;prog&amp;gt;:        0:       r2 = *(u32 *)(r1 + 80)        1:       r1 = *(u32 *)(r1 + 76)        2:       r3 = r1        3:       r3 += 4        4:       if r3 &amp;gt; r2 goto +18 &amp;lt;LBB5_5&amp;gt;        5:       w2 = 0        6:       *(u32 *)(r1 + 0) = r2        7:       r1 = *(u32 *)(r1 + 0)        8:       r2 = 1        9:       if w1 == 0 goto +1 &amp;lt;LBB5_3&amp;gt;       10:       r2 = -1 0000000000000058 &amp;lt;LBB5_3&amp;gt;:       11:       r1 = 0 ll       13:       r3 = 0       14:       call bpf_ringbuf_reserve       15:       if r0 == 0 goto +7 &amp;lt;LBB5_5&amp;gt;       16:       r1 = r0       17:       r1 += 16777215       18:       w2 = 0       19:       *(u8 *)(r…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49961</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>
