<?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 03:37:25 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-05875</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-05875</link>
      <description>bdu:2026-05875</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-05875</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53221</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53221</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: 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:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53221</guid>
    </item>
    <item>
      <title>certfr-2025-avi-0895 — 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-2025-avi-0895</link>
      <description>certfr-2025-avi-0895</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0895</guid>
    </item>
    <item>
      <title>EUVD-2026-320465</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-320465</link>
      <description>EUVD-2026-320465</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-320465</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53221</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53221</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Fix memleak due to fentry attach failure&lt;/p&gt;
&lt;p&gt;If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;This meamleak can be verified by a simple bpf program as follows:&lt;/p&gt;
&lt;p&gt;SEC(&amp;#34;fentry/trap_init&amp;#34;)
  int fentry_run()
  {
      return 0;
  }&lt;/p&gt;
&lt;p&gt;It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;$ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]&lt;/p&gt;
&lt;p&gt;$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &amp;#34;FUNC &amp;#39;trap_init&amp;#39;&amp;#34;
  [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static&lt;/p&gt;
&lt;p&gt;$ echo $((6442453466 &amp;amp; 0x7fffffff))
  2522&lt;/p&gt;
&lt;p&gt;Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.&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: Fix memleak due to fentry attach failure&lt;/p&gt;
&lt;p&gt;If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;This meamleak can be verified by a simple bpf program as follows:&lt;/p&gt;
&lt;p&gt;SEC(&amp;#34;fentry/trap_init&amp;#34;)
  int fentry_run()
  {
      return 0;
  }&lt;/p&gt;
&lt;p&gt;It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;$ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]&lt;/p&gt;
&lt;p&gt;$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &amp;#34;FUNC &amp;#39;trap_init&amp;#39;&amp;#34;
  [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static&lt;/p&gt;
&lt;p&gt;$ echo $((6442453466 &amp;amp; 0x7fffffff))
  2522&lt;/p&gt;
&lt;p&gt;Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53221</guid>
    </item>
    <item>
      <title>GHSA-2px5-v96w-8g69</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-2px5-v96w-8g69</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: Fix memleak due to fentry attach failure&lt;/p&gt;
&lt;p&gt;If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;This meamleak can be verified by a simple bpf program as follows:&lt;/p&gt;
&lt;p&gt;SEC(&amp;#34;fentry/trap_init&amp;#34;)
  int fentry_run()
  {
      return 0;
  }&lt;/p&gt;
&lt;p&gt;It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;$ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]&lt;/p&gt;
&lt;p&gt;$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &amp;#34;FUNC &amp;#39;trap_init&amp;#39;&amp;#34;
  [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static&lt;/p&gt;
&lt;p&gt;$ echo $((6442453466 &amp;amp; 0x7fffffff))
  2522&lt;/p&gt;
&lt;p&gt;Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.&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: Fix memleak due to fentry attach failure&lt;/p&gt;
&lt;p&gt;If it fails to attach fentry, the allocated bpf trampoline image will be
left in the system. That can be verified by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;This meamleak can be verified by a simple bpf program as follows:&lt;/p&gt;
&lt;p&gt;SEC(&amp;#34;fentry/trap_init&amp;#34;)
  int fentry_run()
  {
      return 0;
  }&lt;/p&gt;
&lt;p&gt;It will fail to attach trap_init because this function is freed after
kernel init, and then we can find the trampoline image is left in the
system by checking /proc/kallsyms.&lt;/p&gt;
&lt;p&gt;$ tail /proc/kallsyms
  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]
  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]&lt;/p&gt;
&lt;p&gt;$ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &amp;#34;FUNC &amp;#39;trap_init&amp;#39;&amp;#34;
  [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static&lt;/p&gt;
&lt;p&gt;$ echo $((6442453466 &amp;amp; 0x7fffffff))
  2522&lt;/p&gt;
&lt;p&gt;Note that there are two left bpf trampoline images, that is because the
libbpf will fallback to raw tracepoint if -EINVAL is returned.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-2px5-v96w-8g69</guid>
    </item>
    <item>
      <title>msrc_CVE-2023-53221 — bpf: Fix memleak due to fentry attach failure</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2023-53221</link>
      <description>msrc_CVE-2023-53221</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2023-53221</guid>
    </item>
    <item>
      <title>OESA-2025-2349 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2025-2349</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;tracing: Fix reading strings from synthetic events&lt;/p&gt;
&lt;p&gt;The follow commands caused a crash:&lt;/p&gt;
&lt;p&gt;# cd /sys/kernel/tracing
  # echo &amp;amp;apos;s:open char file[]&amp;amp;apos; &amp;amp;gt; dynamic_events
  # echo &amp;amp;apos;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;amp;apos; &amp;amp;gt; events/syscalls/sys_enter_openat/trigger&amp;amp;apos;
  # echo 1 &amp;amp;gt; events/synthetic/open/enable&lt;/p&gt;
&lt;p&gt;BOOM!&lt;/p&gt;
&lt;p&gt;The problem is that the synthetic event field &amp;amp;quot;char file[]&amp;amp;quot; will read
the value given to it as a string without any memory checks to make sure
the address is valid. The above example will pass in the user space
address and the sythetic event code will happily call strlen() on it
and then strscpy() where either one will cause an oops when accessing
user space addresses.&lt;/p&gt;
&lt;p&gt;Use the helper functions from trace_kprobe and trace_eprobe that can
read strings safely (and actually succeed when the address is from user
space and the memory is mapped in).&lt;/p&gt;
&lt;p&gt;Now the above can show:&lt;/p&gt;
&lt;p&gt;packagekitd-1721    [000] ...2.   104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr
    in:imjournal-978     [006] ...2.   104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp
     packagekitd-1721    [000] ...2.   104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr(CVE-2022-50255)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kprobes: Fix check…&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;tracing: Fix reading strings from synthetic events&lt;/p&gt;
&lt;p&gt;The follow commands caused a crash:&lt;/p&gt;
&lt;p&gt;# cd /sys/kernel/tracing
  # echo &amp;amp;apos;s:open char file[]&amp;amp;apos; &amp;amp;gt; dynamic_events
  # echo &amp;amp;apos;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;amp;apos; &amp;amp;gt; events/syscalls/sys_enter_openat/trigger&amp;amp;apos;
  # echo 1 &amp;amp;gt; events/synthetic/open/enable&lt;/p&gt;
&lt;p&gt;BOOM!&lt;/p&gt;
&lt;p&gt;The problem is that the synthetic event field &amp;amp;quot;char file[]&amp;amp;quot; will read
the value given to it as a string without any memory checks to make sure
the address is valid. The above example will pass in the user space
address and the sythetic event code will happily call strlen() on it
and then strscpy() where either one will cause an oops when accessing
user space addresses.&lt;/p&gt;
&lt;p&gt;Use the helper functions from trace_kprobe and trace_eprobe that can
read strings safely (and actually succeed when the address is from user
space and the memory is mapped in).&lt;/p&gt;
&lt;p&gt;Now the above can show:&lt;/p&gt;
&lt;p&gt;packagekitd-1721    [000] ...2.   104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr
    in:imjournal-978     [006] ...2.   104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp
     packagekitd-1721    [000] ...2.   104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr(CVE-2022-50255)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;kprobes: Fix check…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2025-2349</guid>
    </item>
    <item>
      <title>RHSA-2024:2394 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2024:2394</link>
      <description>&lt;p&gt;kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don&amp;#39;t allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order &amp;gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack kernel: ovl: fix warning in ovl_create_real() kernel: memcg does not limit the number of POSIX file locks allowing memory exhaustion kernel: vmwgfx: NULL pointer dereference in vmw_cmd_dx_define_query kernel: integer overflow in l2cap_config_req() in net/bluetooth/l2cap_core.c kernel: i2c: mlxbf: prevent stack overflow in mlxbf_i2c_smbus_start_transaction() kernel: Bluetooth: L2CAP: Fix u8 overflow kernel: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() kernel: tracing: Fix sleeping function called from invalid context on RT kernel kernel: net: mdio: unexport __init-annotated mdio_bus_init() kernel: arm64: ftrace: consistently handle PLTs. kernel: mm/uffd: fix pte marker when fork() without fork event kernel: Bluetooth: Fix a buffer overflow in mgmt_mesh_add() kernel: tty: n_gsm: add sanity check for gsm-&amp;gt;receive in gsm_receive_buf() kernel: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead kernel: tee: add overflow check in register_shm_helper() kernel: tty: n_gsm: fix deadlock and link starvation in outgoing data path kernel: PM: hibernate: defer device probing when resuming from hibernation kernel: ext4: don&amp;#39;t allow journal inode to have encrypt flag kernel: ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline kernel: erofs: fix order &amp;gt;= MAX_ORDER warning due to crafted negative i_size kernel: perf/x86/intel/uncore: F…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2024:2394</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:03600-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03600-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-2025:03600-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53221</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53221</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 117 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memleak due to fentry attach failure If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms. This meamleak can be verified by a simple bpf program as follows:   SEC(&amp;#34;fentry/trap_init&amp;#34;)   int fentry_run()   {       return 0;   } It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms.   $ tail /proc/kallsyms   ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]   ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]   $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &amp;#34;FUNC &amp;#39;trap_init&amp;#39;&amp;#34;   [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static   $ echo $((6442453466 &amp;amp; 0x7fffffff))   2522 Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned.&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 117 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memleak due to fentry attach failure If it fails to attach fentry, the allocated bpf trampoline image will be left in the system. That can be verified by checking /proc/kallsyms. This meamleak can be verified by a simple bpf program as follows:   SEC(&amp;#34;fentry/trap_init&amp;#34;)   int fentry_run()   {       return 0;   } It will fail to attach trap_init because this function is freed after kernel init, and then we can find the trampoline image is left in the system by checking /proc/kallsyms.   $ tail /proc/kallsyms   ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]   ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]   $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep &amp;#34;FUNC &amp;#39;trap_init&amp;#39;&amp;#34;   [2522] FUNC &amp;#39;trap_init&amp;#39; type_id=119 linkage=static   $ echo $((6442453466 &amp;amp; 0x7fffffff))   2522 Note that there are two left bpf trampoline images, that is because the libbpf will fallback to raw tracepoint if -EINVAL is returned.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53221</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2053 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2053</guid>
    </item>
  </channel>
</rss>
