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 l2tp_core 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 listforeachentry_rcu() 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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/64xxx/CVE-2026-64119.json",
"cna_assigner": "Linux"
}