CVE-2026-64119: l2tp: use list_del_rcu in l2tp_session_unhash

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

l2tp: use listdelrcu in l2tpsessionunhash

An unprivileged local user can pin a host CPU indefinitely in l2tpsessiongetbyifname() by issuing L2TPCMDSESSIONGET on L2TPATTRIFNAME concurrently with L2TPCMDSESSIONCREATE and L2TPCMDSESSIONDELETE on the same tunnel. All three commands take GENLUNSADMINPERM, so CAPNETADMIN in the netns user namespace suffices; on any host that has l2tpcore loaded the trigger is reachable from a standard unshare -Urn sandbox.

l2tpsessionunhash() removes a session from tunnel->sessionlist with listdelinit(), but that list is walked by l2tpsessiongetbyifname() with listforeachentryrcu() under rcureadlockbh(). listdelinit() leaves the deleted entry's next/prev self-pointing; a reader that has loaded the entry and then advances pos->list.next reads &session->list, containerof()s back to the same session, and listforeachentryrcu() never reaches the list head. The CPU stays in strcmp() inside the walker, with BH and preemption disabled, so RCU grace periods on the host stall behind it and the wedged thread cannot be killed (SIGKILL is delivered on syscall return).

Use listdelrcu() to match the existing listaddrcu() in l2tpsessionregister(); the deleted session remains visible to in-flight walkers with consistent next/prev pointers until kfreercu() in l2tpsessionfree() releases it. tunnel->sessionlist has exactly one listdelinit() call site; the listdelinit (&session->clist) at l2tpcore.c:533 operates on the per-collision list, which is not walked under RCU. listempty(&session->list) is not used anywhere in net/l2tp/ after the unhash point, so dropping the post-delete self-init is safe; the fix has no userspace-visible behavior change.