Cross-reference: this looks like the same regression as bug #2169269 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169269), filed 2026-10-02 by Zickzackzuck, which I only came across today.
What matches: * same version boundary: 6.8.0-142 good -> 6.8.0-146 bad, noble/24.04 * same failure class: refcount_t "addition on 0; use-after-free" on an L2TP session object, followed by a hard hang requiring power cycle * same trigger: L2TP over IPsec (ESP-in-UDP), on every tunnel bring-up Where the two differ is only the path the splat is observed on. In #2169269 the trace goes through l2tp_tunnel_get_session() reached from xfrm_trans_reinject() during ESP-in-UDP decapsulation. On my host the only l2tp object that actually changed between -142 and -146 is l2tp_ppp.ko -- l2tp_core.ko is identical between the two builds -- and my suspicion is the session refcount handling in pppol2tp_ioctl() touched by the CVE-2026-53262 backport. Both observations are consistent with one underlying session-refcount imbalance being reached from two different callers, rather than with two separate defects. So there are now two independent reporters on different hardware and different deployments hitting this within days of each other. If the kernel team concludes it is one defect, please feel free to mark this report as a duplicate of #2169269 -- that one was filed first; I would just ask that the pstore dumps attached here stay linked to whichever report is kept open. One more data point that may help narrow the trigger: the crash only happens when the L2TP tunnel actually comes up in the kernel. On a public-IP uplink, where ppp0 is established ~19 s into boot, the box died twice within 46 s and 108 s of boot. Behind NAT, where strongSwan stays in CONNECTING and no L2TP session is ever created, the same box on the same -146 kernel stayed up for 12-17 minutes with no splat at all. Current workaround here: pinned back to 6.8.0-142 via GRUB_DEFAULT plus "apt-mark hold linux-image-generic linux-generic linux-headers-generic", with no recurrence since the rollback. I can reinstall -146 and capture a full lockup trace with the NMI watchdog enabled if that would be useful, but it takes the host down and needs a maintenance window with physical access, so please say whether it is wanted before I schedule it. ** CVE added: https://cve.org/CVERecord?id=CVE-2026-53262 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2169477 Title: [regression] 6.8.0-146: l2tp/pppol2tp use-after-free -> kernel panic / soft lockup (L2TP/IPsec, xl2tpd) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2169477/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
