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

From: Greg Kroah-Hartman <[email protected]>

Description
===========

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

l2tp: use list_del_rcu in l2tp_session_unhash

An unprivileged local user can pin a host CPU indefinitely in
l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on
L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and
L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take
GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace
suffices; on any host that has l2tp_core loaded the trigger is
reachable from a standard `unshare -Urn` sandbox.

l2tp_session_unhash() removes a session from tunnel->session_list
with list_del_init(), but that list is walked by
l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under
rcu_read_lock_bh(). list_del_init() 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, container_of()s
back to the same session, and list_for_each_entry_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 list_del_rcu() to match the existing list_add_rcu() in
l2tp_session_register(); the deleted session remains visible to
in-flight walkers with consistent next/prev pointers until
kfree_rcu() in l2tp_session_free() releases it. tunnel->session_list
has exactly one list_del_init() call site; the list_del_init
(&session->clist) at l2tp_core.c:533 operates on the per-collision
list, which is not walked under RCU. list_empty(&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.

The Linux kernel CVE team has assigned CVE-2026-64119 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 6.12 with commit 89b768ec2dfefaeba5212de14fc71368e12d06ba and fixed in 6.12.92 with commit 5e40919a40cb3e590ed45c2a54a4a2518aa88a99
	Issue introduced in 6.12 with commit 89b768ec2dfefaeba5212de14fc71368e12d06ba and fixed in 6.18.34 with commit e0c3dd7b30cc5ee42ab502da140cda93d794a20b
	Issue introduced in 6.12 with commit 89b768ec2dfefaeba5212de14fc71368e12d06ba and fixed in 7.0.11 with commit acab6314bb75be994f720ed13e9d9139cbf828a8
	Issue introduced in 6.12 with commit 89b768ec2dfefaeba5212de14fc71368e12d06ba and fixed in 7.1 with commit 979c017803c40829b03acd9e5236e354b7622360
	Issue introduced in 6.11.3 with commit b3dd82a879f25db9d096ae3053f657aa4260ecc6

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-64119
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/l2tp/l2tp_core.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/5e40919a40cb3e590ed45c2a54a4a2518aa88a99
	https://git.kernel.org/stable/c/e0c3dd7b30cc5ee42ab502da140cda93d794a20b
	https://git.kernel.org/stable/c/acab6314bb75be994f720ed13e9d9139cbf828a8
	https://git.kernel.org/stable/c/979c017803c40829b03acd9e5236e354b7622360