<?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 22:34:27 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-05953</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-05953</link>
      <description>bdu:2026-05953</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-05953</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-344877</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344877</link>
      <description>EUVD-2026-344877</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344877</guid>
    </item>
    <item>
      <title>fkie_cve-2022-50255</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-50255</link>
      <description>&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;#39;s:open char file[]&amp;#39; &amp;gt; dynamic_events
  # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &amp;gt; events/syscalls/sys_enter_openat/trigger&amp;#39;
  # echo 1 &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;#34;char file[]&amp;#34; 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&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;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;#39;s:open char file[]&amp;#39; &amp;gt; dynamic_events
  # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &amp;gt; events/syscalls/sys_enter_openat/trigger&amp;#39;
  # echo 1 &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;#34;char file[]&amp;#34; 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&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-50255</guid>
    </item>
    <item>
      <title>GHSA-h4gq-9hmg-w96x</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-h4gq-9hmg-w96x</link>
      <description>&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;#39;s:open char file[]&amp;#39; &amp;gt; dynamic_events
  # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &amp;gt; events/syscalls/sys_enter_openat/trigger&amp;#39;
  # echo 1 &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;#34;char file[]&amp;#34; 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&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;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;#39;s:open char file[]&amp;#39; &amp;gt; dynamic_events
  # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &amp;gt; events/syscalls/sys_enter_openat/trigger&amp;#39;
  # echo 1 &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;#34;char file[]&amp;#34; 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&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-h4gq-9hmg-w96x</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>SUSE-SU-2025:03615-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:03615-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:03615-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-50255</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50255</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 101 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracing: Fix reading strings from synthetic events The follow commands caused a crash:   # cd /sys/kernel/tracing   # echo &amp;#39;s:open char file[]&amp;#39; &amp;gt; dynamic_events   # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &amp;gt; events/syscalls/sys_enter_openat/trigger&amp;#39;   # echo 1 &amp;gt; events/synthetic/open/enable BOOM! The problem is that the synthetic event field &amp;#34;char file[]&amp;#34; 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. 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). Now the above can show:      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&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 101 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracing: Fix reading strings from synthetic events The follow commands caused a crash:   # cd /sys/kernel/tracing   # echo &amp;#39;s:open char file[]&amp;#39; &amp;gt; dynamic_events   # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &amp;gt; events/syscalls/sys_enter_openat/trigger&amp;#39;   # echo 1 &amp;gt; events/synthetic/open/enable BOOM! The problem is that the synthetic event field &amp;#34;char file[]&amp;#34; 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. 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). Now the above can show:      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&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-50255</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>
