<?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 21:15:02 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-13844</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-13844</link>
      <description>bdu:2026-13844</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-13844</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-46196</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-46196</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-2026-46196</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0731 — De multiples vulnérabilités ont été découvertes dans les produits Microsoft. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0731</link>
      <description>certfr-2026-avi-0731</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0731</guid>
    </item>
    <item>
      <title>EUVD-2026-328703</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-328703</link>
      <description>EUVD-2026-328703</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-328703</guid>
    </item>
    <item>
      <title>fkie_cve-2026-46196</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46196</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()&lt;/p&gt;
&lt;p&gt;When a tracepoint goes through the 0 -&amp;gt; 1 transition, tracepoint_add_func()
invokes the subsystem&amp;#39;s ext-&amp;gt;regfunc() before attempting to install the
new probe via func_add(). If func_add() then fails (for example, when
allocate_probes() cannot allocate a new probe array under memory pressure
and returns -ENOMEM), the function returns the error without calling the
matching ext-&amp;gt;unregfunc(), leaving the side effects of regfunc() behind
with no installed probe to justify them.&lt;/p&gt;
&lt;p&gt;For syscall tracepoints this is particularly unpleasant: syscall_regfunc()
bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.
After a leaked failure, the refcount is stuck at a non-zero value with no
consumer, and every task continues paying the syscall trace entry/exit
overhead until reboot. Other subsystems providing regfunc()/unregfunc()
pairs exhibit similarly scoped persistent state.&lt;/p&gt;
&lt;p&gt;Mirror the existing 1 -&amp;gt; 0 cleanup and call ext-&amp;gt;unregfunc() in the
func_add() error path, gated on the same condition used there so the
unwind is symmetric with the registration.&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;tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()&lt;/p&gt;
&lt;p&gt;When a tracepoint goes through the 0 -&amp;gt; 1 transition, tracepoint_add_func()
invokes the subsystem&amp;#39;s ext-&amp;gt;regfunc() before attempting to install the
new probe via func_add(). If func_add() then fails (for example, when
allocate_probes() cannot allocate a new probe array under memory pressure
and returns -ENOMEM), the function returns the error without calling the
matching ext-&amp;gt;unregfunc(), leaving the side effects of regfunc() behind
with no installed probe to justify them.&lt;/p&gt;
&lt;p&gt;For syscall tracepoints this is particularly unpleasant: syscall_regfunc()
bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.
After a leaked failure, the refcount is stuck at a non-zero value with no
consumer, and every task continues paying the syscall trace entry/exit
overhead until reboot. Other subsystems providing regfunc()/unregfunc()
pairs exhibit similarly scoped persistent state.&lt;/p&gt;
&lt;p&gt;Mirror the existing 1 -&amp;gt; 0 cleanup and call ext-&amp;gt;unregfunc() in the
func_add() error path, gated on the same condition used there so the
unwind is symmetric with the registration.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-46196</guid>
    </item>
    <item>
      <title>GHSA-3j98-4vrc-2fpm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-3j98-4vrc-2fpm</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()&lt;/p&gt;
&lt;p&gt;When a tracepoint goes through the 0 -&amp;gt; 1 transition, tracepoint_add_func()
invokes the subsystem&amp;#39;s ext-&amp;gt;regfunc() before attempting to install the
new probe via func_add(). If func_add() then fails (for example, when
allocate_probes() cannot allocate a new probe array under memory pressure
and returns -ENOMEM), the function returns the error without calling the
matching ext-&amp;gt;unregfunc(), leaving the side effects of regfunc() behind
with no installed probe to justify them.&lt;/p&gt;
&lt;p&gt;For syscall tracepoints this is particularly unpleasant: syscall_regfunc()
bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.
After a leaked failure, the refcount is stuck at a non-zero value with no
consumer, and every task continues paying the syscall trace entry/exit
overhead until reboot. Other subsystems providing regfunc()/unregfunc()
pairs exhibit similarly scoped persistent state.&lt;/p&gt;
&lt;p&gt;Mirror the existing 1 -&amp;gt; 0 cleanup and call ext-&amp;gt;unregfunc() in the
func_add() error path, gated on the same condition used there so the
unwind is symmetric with the registration.&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;tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()&lt;/p&gt;
&lt;p&gt;When a tracepoint goes through the 0 -&amp;gt; 1 transition, tracepoint_add_func()
invokes the subsystem&amp;#39;s ext-&amp;gt;regfunc() before attempting to install the
new probe via func_add(). If func_add() then fails (for example, when
allocate_probes() cannot allocate a new probe array under memory pressure
and returns -ENOMEM), the function returns the error without calling the
matching ext-&amp;gt;unregfunc(), leaving the side effects of regfunc() behind
with no installed probe to justify them.&lt;/p&gt;
&lt;p&gt;For syscall tracepoints this is particularly unpleasant: syscall_regfunc()
bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task.
After a leaked failure, the refcount is stuck at a non-zero value with no
consumer, and every task continues paying the syscall trace entry/exit
overhead until reboot. Other subsystems providing regfunc()/unregfunc()
pairs exhibit similarly scoped persistent state.&lt;/p&gt;
&lt;p&gt;Mirror the existing 1 -&amp;gt; 0 cleanup and call ext-&amp;gt;unregfunc() in the
func_add() error path, gated on the same condition used there so the
unwind is symmetric with the registration.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-3j98-4vrc-2fpm</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-46196 — tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-46196</link>
      <description>msrc_CVE-2026-46196</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-46196</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:10954-1 — kernel-devel-7.0.11-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:10954-1</link>
      <description>&lt;p&gt;kernel-devel-7.0.11-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.0.11-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:10954-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-46196</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46196</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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -&amp;gt; 1 transition, tracepoint_add_func() invokes the subsystem&amp;#39;s ext-&amp;gt;regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext-&amp;gt;unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -&amp;gt; 0 cleanup and call ext-&amp;gt;unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.&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 246 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: tracepoint: balance regfunc() on func_add() failure in tracepoint_add_func() When a tracepoint goes through the 0 -&amp;gt; 1 transition, tracepoint_add_func() invokes the subsystem&amp;#39;s ext-&amp;gt;regfunc() before attempting to install the new probe via func_add(). If func_add() then fails (for example, when allocate_probes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext-&amp;gt;unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them. For syscall tracepoints this is particularly unpleasant: syscall_regfunc() bumps sys_tracepoint_refcount and sets SYSCALL_TRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state. Mirror the existing 1 -&amp;gt; 0 cleanup and call ext-&amp;gt;unregfunc() in the func_add() error path, gated on the same condition used there so the unwind is symmetric with the registration.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-46196</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1700 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte 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 andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1700</guid>
    </item>
  </channel>
</rss>
