<?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://vulnerability.circl.lu</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>Thu, 01 Oct 2026 06:58:41 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-68415 — xfrm: clear mode callbacks after failed mode setup</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-68415</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xfrm: clear mode callbacks after failed mode setup&lt;/p&gt;
&lt;p&gt;xfrm_state_gc_task can run long after a failed IPTFS state setup. In the
reproduced case, __xfrm_init_state() cached x-&amp;gt;mode_cbs, IPTFS setup
returned -ENOMEM before publishing mode_data, and the temporary module
reference from xfrm_get_mode_cbs() was dropped immediately. The dead state
then kept x-&amp;gt;mode_cbs until deferred GC ran after xfrm_iptfs had been
unloaded.&lt;/p&gt;
&lt;p&gt;Clear x-&amp;gt;mode_cbs when mode init or clone fails before publishing
mode_data. Those states never installed mode-specific state or the
long-term IPTFS module pin, so deferred GC has nothing mode-specific to
destroy and must not retain a callback table pointer past the temporary
lookup reference.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the order
within that path:&lt;/p&gt;
&lt;p&gt;failed setup path:
1. cache x-&amp;gt;mode_cbs
2. mode setup fails before mode_data
3. drop the temporary module ref
4. dead state keeps x-&amp;gt;mode_cbs cached&lt;/p&gt;
&lt;p&gt;GC/unload path:
1. xfrm_state_put() queues GC work
2. xfrm_iptfs unloads later
3. xfrm_state_gc_task runs
4. GC dereferences stale x-&amp;gt;mode_cbs&lt;/p&gt;
&lt;p&gt;This also covers the failed clone path where clone_state() returns before
publishing mode_data.&lt;/p&gt;
&lt;p&gt;Validation reproduced this kernel report:
Kernel panic - not syncing: Fatal exception
CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
failslab_stacktrace_filter matched xfrm_iptfs frames
ack_error=-12
FAULT_INJECTION: forcing a failur…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;xfrm: clear mode callbacks after failed mode setup&lt;/p&gt;
&lt;p&gt;xfrm_state_gc_task can run long after a failed IPTFS state setup. In the
reproduced case, __xfrm_init_state() cached x-&amp;gt;mode_cbs, IPTFS setup
returned -ENOMEM before publishing mode_data, and the temporary module
reference from xfrm_get_mode_cbs() was dropped immediately. The dead state
then kept x-&amp;gt;mode_cbs until deferred GC ran after xfrm_iptfs had been
unloaded.&lt;/p&gt;
&lt;p&gt;Clear x-&amp;gt;mode_cbs when mode init or clone fails before publishing
mode_data. Those states never installed mode-specific state or the
long-term IPTFS module pin, so deferred GC has nothing mode-specific to
destroy and must not retain a callback table pointer past the temporary
lookup reference.&lt;/p&gt;
&lt;p&gt;The buggy scenario involves two paths, with each column showing the order
within that path:&lt;/p&gt;
&lt;p&gt;failed setup path:
1. cache x-&amp;gt;mode_cbs
2. mode setup fails before mode_data
3. drop the temporary module ref
4. dead state keeps x-&amp;gt;mode_cbs cached&lt;/p&gt;
&lt;p&gt;GC/unload path:
1. xfrm_state_put() queues GC work
2. xfrm_iptfs unloads later
3. xfrm_state_gc_task runs
4. GC dereferences stale x-&amp;gt;mode_cbs&lt;/p&gt;
&lt;p&gt;This also covers the failed clone path where clone_state() returns before
publishing mode_data.&lt;/p&gt;
&lt;p&gt;Validation reproduced this kernel report:
Kernel panic - not syncing: Fatal exception
CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
failslab_stacktrace_filter matched xfrm_iptfs frames
ack_error=-12
FAULT_INJECTION: forcing a failur…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-68415</guid>
    </item>
  </channel>
</rss>
