<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T06:58:41.494481+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-68415</id>
    <title>CVE-2026-68415 — xfrm: clear mode callbacks after failed mode setup</title>
    <updated>2026-10-01T06:58:41.495914+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>xfrm: clear mode callbacks after failed mode setup</p>
<p>xfrm_state_gc_task can run long after a failed IPTFS state setup. In the
reproduced case, __xfrm_init_state() cached x-&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-&gt;mode_cbs until deferred GC ran after xfrm_iptfs had been
unloaded.</p>
<p>Clear x-&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.</p>
<p>The buggy scenario involves two paths, with each column showing the order
within that path:</p>
<p>failed setup path:
1. cache x-&gt;mode_cbs
2. mode setup fails before mode_data
3. drop the temporary module ref
4. dead state keeps x-&gt;mode_cbs cached</p>
<p>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-&gt;mode_cbs</p>
<p>This also covers the failed clone path where clone_state() returns before
publishing mode_data.</p>
<p>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…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-68415"/>
  </entry>
</feed>
