From: Jakub Kicinski <kuba@kernel.org>
To: michael.bommarito@gmail.com
Cc: Simon Horman <horms@kernel.org>,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
jchapman@katalix.com, tparkin@katalix.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] l2tp: use list_del_rcu in l2tp_session_unhash
Date: Thu, 21 May 2026 07:46:23 -0700 [thread overview]
Message-ID: <20260521074623.15efef0f@kernel.org> (raw)
In-Reply-To: <20260521143654.1980290-1-horms@kernel.org>
On Thu, 21 May 2026 15:36:53 +0100 Simon Horman wrote:
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> 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() when l2tp_session_unhash() uses list_del_init()
> while the list is being walked under RCU. This commit changes
> l2tp_session_unhash() to use list_del_rcu() to match the existing
> list_add_rcu(), preventing the infinite loop.
>
> > diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> > index 157fc23ce4e14..1455f67e01ddb 100644
> > --- a/net/l2tp/l2tp_core.c
> > +++ b/net/l2tp/l2tp_core.c
> > @@ -1360,7 +1360,7 @@ static void l2tp_session_unhash(struct l2tp_session *session)
> > spin_lock_bh(&pn->l2tp_session_idr_lock);
> >
> > /* Remove from the per-tunnel list */
> > - list_del_init(&session->list);
> > + list_del_rcu(&session->list);
>
> Can this change lead to a use-after-free in l2tp_session_get_by_ifname()?
>
> By switching to list_del_rcu(), the deleted session remains visible to
> in-flight RCU readers. If l2tp_session_del_work() drops the session's
> reference count to 0 concurrently, the session will be queued for
> destruction via kfree_rcu().
Saw this, but I don't get how list_del_init() -> list_del_rcu()
can change visibility to the readers :| Without digging into the code
this reads like Gemini reporting a different pre-existing issue.
Michael, could you investigate?
> If an in-flight RCU reader in l2tp_session_get_by_ifname() encounters
> this session before the grace period ends, it will execute:
>
> list_for_each_entry_rcu(session, &tunnel->session_list, list) {
> if (!strcmp(session->ifname, ifname)) {
> refcount_inc(&session->ref_count);
> rcu_read_unlock_bh();
> return session;
> }
> }
>
> Since refcount_inc() does not protect against zero-reference transitions,
> the reader will obtain a pointer to a session that is already pending
> destruction.
>
> Once the RCU grace period expires, kfree_rcu() will free the session
> memory, causing a use-after-free for the caller.
>
> Should l2tp_session_get_by_ifname() use refcount_inc_not_zero() and skip
> the session if it returns false, similar to other getters like
> l2tp_v3_session_get()?
next prev parent reply other threads:[~2026-05-21 14:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 18:34 [PATCH net] l2tp: use list_del_rcu in l2tp_session_unhash Michael Bommarito
2026-05-21 14:36 ` Simon Horman
2026-05-21 14:46 ` Jakub Kicinski [this message]
2026-05-21 16:00 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260521074623.15efef0f@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jchapman@katalix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.bommarito@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=tparkin@katalix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.