CVE-2026-68415: xfrm: clear mode callbacks after failed mode setup

In the Linux kernel, the following vulnerability has been resolved:

xfrm: clear mode callbacks after failed mode setup

xfrmstategctask can run long after a failed IPTFS state setup. In the reproduced case, xfrminitstate() cached x->modecbs, IPTFS setup returned -ENOMEM before publishing modedata, and the temporary module reference from xfrmgetmodecbs() was dropped immediately. The dead state then kept x->modecbs until deferred GC ran after xfrmiptfs had been unloaded.

Clear x->modecbs when mode init or clone fails before publishing modedata. 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.

The buggy scenario involves two paths, with each column showing the order within that path:

failed setup path: 1. cache x->modecbs 2. mode setup fails before modedata 3. drop the temporary module ref 4. dead state keeps x->modecbs cached

GC/unload path: 1. xfrmstateput() queues GC work 2. xfrmiptfs unloads later 3. xfrmstategctask runs 4. GC dereferences stale x->modecbs

This also covers the failed clone path where clonestate() returns before publishing modedata.

Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIGFAULTINJECTIONSTACKTRACEFILTER=y failslabstacktracefilter matched xfrmiptfs frames ackerror=-12 FAULTINJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrmstategctask RIP: xfrmstategctask+0x142/0x650 Modules linked in: esp4offload xfrmuser [last unloaded: xfrmiptfs] Kernel panic - not syncing: Fatal exception