<?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 11:56:38 +0000</lastBuildDate>
    <item>
      <title>bdu:2024-07746</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2024-07746</link>
      <description>bdu:2024-07746</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2024-07746</guid>
    </item>
    <item>
      <title>BELL-CVE-2024-42161</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2024-42161</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2024-42161</guid>
    </item>
    <item>
      <title>certfr-2024-avi-0693 — 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-0693</link>
      <description>certfr-2024-avi-0693</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2024-avi-0693</guid>
    </item>
    <item>
      <title>cnvd-2024-35101</title>
      <link>https://cve.radiocsirt.org/vuln/cnvd-2024-35101</link>
      <description>cnvd-2024-35101</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cnvd-2024-35101</guid>
    </item>
    <item>
      <title>EUVD-2026-313072</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-313072</link>
      <description>EUVD-2026-313072</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-313072</guid>
    </item>
    <item>
      <title>fkie_cve-2024-42161</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-42161</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD&lt;/p&gt;
&lt;p&gt;[Changes from V1:
 - Use a default branch in the switch statement to initialize `val&amp;#39;.]&lt;/p&gt;
&lt;p&gt;GCC warns that `val&amp;#39; may be used uninitialized in the
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:&lt;/p&gt;
&lt;p&gt;[...]
	unsigned long long val;						      \
	[...]								      \
	switch (__CORE_RELO(s, field, BYTE_SIZE)) {			      \
	case 1: val = *(const unsigned char *)p; break;			      \
	case 2: val = *(const unsigned short *)p; break;		      \
	case 4: val = *(const unsigned int *)p; break;			      \
	case 8: val = *(const unsigned long long *)p; break;		      \
        }       							      \
	[...]
	val;								      \
	}								      \&lt;/p&gt;
&lt;p&gt;This patch adds a default entry in the switch statement that sets
`val&amp;#39; to zero in order to avoid the warning, and random values to be
used in case __builtin_preserve_field_info returns unexpected values
for BPF_FIELD_BYTE_SIZE.&lt;/p&gt;
&lt;p&gt;Tested in bpf-next master.
No regressions.&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: Avoid uninitialized value in BPF_CORE_READ_BITFIELD&lt;/p&gt;
&lt;p&gt;[Changes from V1:
 - Use a default branch in the switch statement to initialize `val&amp;#39;.]&lt;/p&gt;
&lt;p&gt;GCC warns that `val&amp;#39; may be used uninitialized in the
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:&lt;/p&gt;
&lt;p&gt;[...]
	unsigned long long val;						      \
	[...]								      \
	switch (__CORE_RELO(s, field, BYTE_SIZE)) {			      \
	case 1: val = *(const unsigned char *)p; break;			      \
	case 2: val = *(const unsigned short *)p; break;		      \
	case 4: val = *(const unsigned int *)p; break;			      \
	case 8: val = *(const unsigned long long *)p; break;		      \
        }       							      \
	[...]
	val;								      \
	}								      \&lt;/p&gt;
&lt;p&gt;This patch adds a default entry in the switch statement that sets
`val&amp;#39; to zero in order to avoid the warning, and random values to be
used in case __builtin_preserve_field_info returns unexpected values
for BPF_FIELD_BYTE_SIZE.&lt;/p&gt;
&lt;p&gt;Tested in bpf-next master.
No regressions.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-42161</guid>
    </item>
    <item>
      <title>GHSA-5hjg-m862-88fc</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5hjg-m862-88fc</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD&lt;/p&gt;
&lt;p&gt;[Changes from V1:
 - Use a default branch in the switch statement to initialize `val&amp;#39;.]&lt;/p&gt;
&lt;p&gt;GCC warns that `val&amp;#39; may be used uninitialized in the
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:&lt;/p&gt;
&lt;p&gt;[...]
	unsigned long long val;						      \
	[...]								      \
	switch (__CORE_RELO(s, field, BYTE_SIZE)) {			      \
	case 1: val = *(const unsigned char *)p; break;			      \
	case 2: val = *(const unsigned short *)p; break;		      \
	case 4: val = *(const unsigned int *)p; break;			      \
	case 8: val = *(const unsigned long long *)p; break;		      \
        }       							      \
	[...]
	val;								      \
	}								      \&lt;/p&gt;
&lt;p&gt;This patch adds a default entry in the switch statement that sets
`val&amp;#39; to zero in order to avoid the warning, and random values to be
used in case __builtin_preserve_field_info returns unexpected values
for BPF_FIELD_BYTE_SIZE.&lt;/p&gt;
&lt;p&gt;Tested in bpf-next master.
No regressions.&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: Avoid uninitialized value in BPF_CORE_READ_BITFIELD&lt;/p&gt;
&lt;p&gt;[Changes from V1:
 - Use a default branch in the switch statement to initialize `val&amp;#39;.]&lt;/p&gt;
&lt;p&gt;GCC warns that `val&amp;#39; may be used uninitialized in the
BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:&lt;/p&gt;
&lt;p&gt;[...]
	unsigned long long val;						      \
	[...]								      \
	switch (__CORE_RELO(s, field, BYTE_SIZE)) {			      \
	case 1: val = *(const unsigned char *)p; break;			      \
	case 2: val = *(const unsigned short *)p; break;		      \
	case 4: val = *(const unsigned int *)p; break;			      \
	case 8: val = *(const unsigned long long *)p; break;		      \
        }       							      \
	[...]
	val;								      \
	}								      \&lt;/p&gt;
&lt;p&gt;This patch adds a default entry in the switch statement that sets
`val&amp;#39; to zero in order to avoid the warning, and random values to be
used in case __builtin_preserve_field_info returns unexpected values
for BPF_FIELD_BYTE_SIZE.&lt;/p&gt;
&lt;p&gt;Tested in bpf-next master.
No regressions.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5hjg-m862-88fc</guid>
    </item>
    <item>
      <title>ICSA-25-072-03 — Siemens SIMATIC S7-1500 TM MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-25-072-03</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
Squashfs: check the inode number is not the invalid value of zero In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. In the Linux kernel, the following vulnerability has been resolved: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode&amp;#39;s list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn&amp;#39;t happen. In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 (&amp;#34;mm/sparsemem: fix race in accessing memory_section-&amp;gt;usage&amp;#34;) changed pfn_section_valid() to add a READ_ONCE() call around &amp;#34;ms-&amp;gt;usage&amp;#34; to fix a race with section_deactivate() where ms-&amp;gt;usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it. In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don&amp;#39;t see anything check…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&#13;
Squashfs: check the inode number is not the invalid value of zero In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. In the Linux kernel, the following vulnerability has been resolved: filelock: fix potential use-after-free in posix_lock_inode Light Hsieh reported a KASAN UAF warning in trace_posix_lock_inode(). The request pointer had been changed earlier to point to a lock entry that was added to the inode&amp;#39;s list. However, before the tracepoint could fire, another task raced in and freed that lock. Fix this by moving the tracepoint inside the spinlock, which should ensure that this doesn&amp;#39;t happen. In the Linux kernel, the following vulnerability has been resolved: mm: prevent derefencing NULL ptr in pfn_section_valid() Commit 5ec8e8ea8b77 (&amp;#34;mm/sparsemem: fix race in accessing memory_section-&amp;gt;usage&amp;#34;) changed pfn_section_valid() to add a READ_ONCE() call around &amp;#34;ms-&amp;gt;usage&amp;#34; to fix a race with section_deactivate() where ms-&amp;gt;usage can be cleared. The READ_ONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it. In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don&amp;#39;t see anything check…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-25-072-03</guid>
    </item>
    <item>
      <title>msrc_CVE-2024-42161 — bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2024-42161</link>
      <description>msrc_CVE-2024-42161</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2024-42161</guid>
    </item>
    <item>
      <title>OESA-2024-1961 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2024-1961</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:&#13;
&#13;
NFSD: Fix the behavior of READ near OFFSET_MAX&#13;
&#13;
Dan Aloni reports:
&amp;amp;gt; Due to commit 8cfb9015280d (&amp;amp;quot;NFS: Always provide aligned buffers to
&amp;amp;gt; the RPC read layers&amp;amp;quot;) on the client, a read of 0xfff is aligned up
&amp;amp;gt; to server rsize of 0x1000.
&amp;amp;gt;
&amp;amp;gt; As a result, in a test where the server has a file of size
&amp;amp;gt; 0x7fffffffffffffff, and the client tries to read from the offset
&amp;amp;gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server
&amp;amp;gt; and it returns an NFS code of EINVAL to the client. The client as
&amp;amp;gt; a result indefinitely retries the request.&#13;
&#13;
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.&#13;
&#13;
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.&#13;
&#13;
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb-&amp;amp;gt;s_maxbytes do not work properly.(CVE-2022-48827)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
net: can: j1939: enhanced error handlin…&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:&#13;
&#13;
NFSD: Fix the behavior of READ near OFFSET_MAX&#13;
&#13;
Dan Aloni reports:
&amp;amp;gt; Due to commit 8cfb9015280d (&amp;amp;quot;NFS: Always provide aligned buffers to
&amp;amp;gt; the RPC read layers&amp;amp;quot;) on the client, a read of 0xfff is aligned up
&amp;amp;gt; to server rsize of 0x1000.
&amp;amp;gt;
&amp;amp;gt; As a result, in a test where the server has a file of size
&amp;amp;gt; 0x7fffffffffffffff, and the client tries to read from the offset
&amp;amp;gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server
&amp;amp;gt; and it returns an NFS code of EINVAL to the client. The client as
&amp;amp;gt; a result indefinitely retries the request.&#13;
&#13;
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.&#13;
&#13;
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.&#13;
&#13;
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb-&amp;amp;gt;s_maxbytes do not work properly.(CVE-2022-48827)&#13;
&#13;
In the Linux kernel, the following vulnerability has been resolved:&#13;
&#13;
net: can: j1939: enhanced error handlin…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2024-1961</guid>
    </item>
    <item>
      <title>SSA-355557 — SSA-355557: Multiple Vulnerabilities in Third-Party Components in SINEC OS before V3.2</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-355557</link>
      <description>&lt;p&gt;nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains 
that target AArch64 allows an attacker to exploit an existing buffer 
overflow in dynamically-sized local variables in your application 
without this being detected. This stack-protector failure only applies 
to C99-style dynamically-sized local variables or those created using 
alloca(). The stack-protector operates as intended for statically-sized 
local variables.&lt;/p&gt;
&lt;p&gt;The default behavior when the stack-protector 
detects an overflow is to terminate your application, resulting…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;nfsd: NULL dereference in nfs3svc_encode_getaclres. scsi: core: use-after-free vulnerability. NFSD: vulnerability caused by loff_t overflow on the server when a client reads near the maximum offset, causing the server to return an EINVAL error, which the client retries indefinitely, instead of handling out-of-range READ requests by returning a short result with an EOF flag. NFSD: Vulnerability caused by an underflow in ia_size due to a mismatch between signed and unsigned 64-bit file size values, which can cause issues when handling large file sizes from NFS clients. NFSD: Vulnerability handling large file sizes for NFSv3 improperly capping client size values larger than s64_max, leading to unexpected behavior and potential data corruption. sh: cpuinfo: warning for CONFIG_CPUMASK_OFFSTACK. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, cpu_max_bits_warn() generates a runtime warning when showing /proc/cpuinfo. A failure in the -fstack-protector feature in GCC-based toolchains 
that target AArch64 allows an attacker to exploit an existing buffer 
overflow in dynamically-sized local variables in your application 
without this being detected. This stack-protector failure only applies 
to C99-style dynamically-sized local variables or those created using 
alloca(). The stack-protector operates as intended for statically-sized 
local variables.&lt;/p&gt;
&lt;p&gt;The default behavior when the stack-protector 
detects an overflow is to terminate your application, resulting…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-355557</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:2894-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:2894-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:2894-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2024-42161</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42161</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 131 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [Changes from V1:  - Use a default branch in the switch statement to initialize `val&amp;#39;.] GCC warns that `val&amp;#39; may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: 	[...] 	unsigned long long val;						      \ 	[...]								      \ 	switch (__CORE_RELO(s, field, BYTE_SIZE)) {			      \ 	case 1: val = *(const unsigned char *)p; break;			      \ 	case 2: val = *(const unsigned short *)p; break;		      \ 	case 4: val = *(const unsigned int *)p; break;			      \ 	case 8: val = *(const unsigned long long *)p; break;		      \         }       							      \ 	[...] 	val;								      \ 	}								      \ This patch adds a default entry in the switch statement that sets `val&amp;#39; to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions.&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 131 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [Changes from V1:  - Use a default branch in the switch statement to initialize `val&amp;#39;.] GCC warns that `val&amp;#39; may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: 	[...] 	unsigned long long val;						      \ 	[...]								      \ 	switch (__CORE_RELO(s, field, BYTE_SIZE)) {			      \ 	case 1: val = *(const unsigned char *)p; break;			      \ 	case 2: val = *(const unsigned short *)p; break;		      \ 	case 4: val = *(const unsigned int *)p; break;			      \ 	case 8: val = *(const unsigned long long *)p; break;		      \         }       							      \ 	[...] 	val;								      \ 	}								      \ This patch adds a default entry in the switch statement that sets `val&amp;#39; to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-42161</guid>
    </item>
    <item>
      <title>WID-SEC-W-2024-1722 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1722</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2024-1722</guid>
    </item>
  </channel>
</rss>
