UBUNTU-CVE-2026-68415: High severity ubuntu/linux-hwe-edge vulnerability
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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-nvidia-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1024.25~24.04.1 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-nvidia-bosto a version that resolves this vulnerability.Fixed in 7.0.0-2022.23 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1
Event History
Frequently Asked Questions
What level of access is needed to exploit this issue?
The vulnerability has a local attack vector and requires low privileges. No user interaction is required.
Which systems are exposed to the stale callback path?
The described path requires an IPTFS XFRM state setup or clone to fail before mode_data is published, followed by the temporary module reference being dropped. The dead state must then be queued for deferred garbage collection and xfrm_iptfs must unload before the GC task dereferences the retained callback pointer.