CVE-2026-63918

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

l2tp: use refcountincnotzero in l2tpsessiongetby_ifname

A reader in l2tpsessiongetbyifname() can return a pointer to a session whose refcount has reached zero. The getter takes its reference with plain refcountinc(), but every other session getter in the same file (l2tpv2sessionget, l2tpv3sessionget, and the corresponding getnext variants) uses refcountincnotzero() because the IDR/RCU lookup can race with refcountdecandtest() -> l2tpsessionfree() -> kfreercu(). The ifname getter is the only outlier; the inconsistency was raised on-list after 979c017803c4 ("l2tp: use listdelrcu in l2tpsessionunhash").

A reader inside rcureadlockbh() that matches session->ifname can be preempted between the strcmp() and the refcountinc(). If the last reference drops on another CPU in that window, the reader's refcountinc() runs on a counter that has reached zero. refcountt catches the addition-on-zero, prints "refcountt: addition on 0; use-after-free", saturates the counter, and returns the saturated pointer to the caller. Session memory is held live by the in-flight RCU read section, but the kfreercu() callback queued from l2tpsessionfree() will free it once the grace period closes; a caller that dereferences the returned session past that point hits a slab-use-after-free. On PREEMPTRT localbhdisable() is a per-CPU sleeping lock and the preemption window is real; on stock PREEMPT kernels localbhdisable() is a preemptcount increment that closes the cross-CPU race in practice (see below).

Use refcountincnotzero() and continue the list walk on failure, matching the other session getters in the file. The ifname getter is the only session getter in net/l2tp/ that still uses the bare refcountinc() pattern; this change restores file-internal consistency. The success path is unchanged.