Re: [PATCH net] l2tp: only return sessions of the given tunnel in l2tp_session_get()

[Guillaume Nault <gnault@redhat.com>]

On Mon, Oct 26, 2026 at 08:57:02AM -0400, Hengyu Liang wrote:
> Hi Guillaume,
> 
> Thanks for looking at this.
> 
> I wasn't sure about the intended semantics. l2tp.rst says "L2TPv3
> session ids are unique across all tunnels", but it also says Linux
> allows the same ID in different tunnels, told apart by sk, and
> l2tp_session_register() still allows that for UDP encap.

My understanding is that L2TPv3 session IDs are unique across their
network namespace. There's an exception for those that are transported
over UDP, as they're now unique for a given UDP socket (the one of
their parent's tunnel).

As a result, looking up a UDP L2TPv3 session requires a socket and a
session ID. That works when demultiplexing an incomming packet, as we
have both information in this case. But that's a problem when selecting
a session from user space.

The correct approach would be to pass both a session ID and a socket
for any L2TPv3 UDP session lookup. But the netlink interface currently
doesn't support passing a socket fd for SESSION_GET, SESSION_MODIFY
and SESSION_DELETE operations. That could be done for managed tunnels
though.

However, for unmanaged tunnels, as used by iproute2, user space doesn't
know anything about the UDP socket. In that case, all we can do is to
replace the socket parameter with a tunnel ID. Then we'd have to loop
through all the sessions that match the requested session ID and return
the one whose tunnel's socket matches the socket of the tunnel ID
passed as parameter. This last operation could maybe be simplified to a
simple tunnel ID check, as, in my understanding, we have an 1:1
relationship between tunnel IDs and their sockets (but I'm a bit wary
of such shortcuts given that code have proved to be brittle in the past).

> The patch only changes callers of l2tp_session_get() that pass a
> tunnel_id, and the result differs from v6.8:
> 
>  - pppol2tp_connect() for session 5 in tunnel 2 fails with EEXIST if
>    tunnel 1 (another UDP socket) already has a connected session 5.
>  - "ip l2tp del session tunnel_id 4 session_id 7" deletes tunnel 3's
>    session 7 when only tunnel 3 has it. On v6.8 it fails. l2tp.rst
>    describes CONN_ID there as the parent tunnel of the session.
> Am I misreading the documentation, is the documentation out of date, or
> is this behaviour not intended?
> 
> Thanks,
> Hengyu
>