From: Guillaume Nault <gnault@redhat.com>
To: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net] l2tp: Allow duplicate session creation with UDP
Date: Thu, 16 Jan 2020 13:38:54 +0100 [thread overview]
Message-ID: <20200116123854.GA23974@linux.home> (raw)
In-Reply-To: <20200115223446.7420-1-ridge.kennedy@alliedtelesis.co.nz>
On Thu, Jan 16, 2020 at 11:34:47AM +1300, Ridge Kennedy wrote:
> In the past it was possible to create multiple L2TPv3 sessions with the
> same session id as long as the sessions belonged to different tunnels.
> The resulting sessions had issues when used with IP encapsulated tunnels,
> but worked fine with UDP encapsulated ones. Some applications began to
> rely on this behaviour to avoid having to negotiate unique session ids.
>
> Some time ago a change was made to require session ids to be unique across
> all tunnels, breaking the applications making use of this "feature".
>
> This change relaxes the duplicate session id check to allow duplicates
> if both of the colliding sessions belong to UDP encapsulated tunnels.
>
> Fixes: dbdbc73b4478 ("l2tp: fix duplicate session creation")
> Signed-off-by: Ridge Kennedy <ridge.kennedy@alliedtelesis.co.nz>
> ---
> net/l2tp/l2tp_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index f82ea12bac37..0cc86227c618 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -323,7 +323,9 @@ int l2tp_session_register(struct l2tp_session *session,
> spin_lock_bh(&pn->l2tp_session_hlist_lock);
>
> hlist_for_each_entry(session_walk, g_head, global_hlist)
> - if (session_walk->session_id == session->session_id) {
> + if (session_walk->session_id == session->session_id &&
> + (session_walk->tunnel->encap == L2TP_ENCAPTYPE_IP ||
> + tunnel->encap == L2TP_ENCAPTYPE_IP)) {
> err = -EEXIST;
> goto err_tlock_pnlock;
> }
Well, I think we have a more fundamental problem here. By adding
L2TPoUDP sessions to the global list, we allow cross-talks with L2TPoIP
sessions. That is, if we have an L2TPv3 session X running over UDP and
we receive an L2TP_IP packet targetted at session ID X, then
l2tp_session_get() will return the L2TP_UDP session to l2tp_ip_recv().
I guess l2tp_session_get() should be dropped and l2tp_ip_recv() should
look up the session in the context of its socket, like in the UDP case.
But for the moment, what about just not adding L2TP_UDP sessions to the
global list? That should fix both your problem and the L2TP_UDP/L2TP_IP
cross-talks.
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index f82ea12bac37..f70fea8d093d 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -316,7 +316,7 @@ int l2tp_session_register(struct l2tp_session *session,
goto err_tlock;
}
- if (tunnel->version == L2TP_HDR_VER_3) {
+ if (tunnel->encap == L2TP_ENCAPTYPE_IP) {
pn = l2tp_pernet(tunnel->l2tp_net);
g_head = l2tp_session_id_hash_2(pn, session->session_id);
@@ -1587,8 +1587,8 @@ void __l2tp_session_unhash(struct l2tp_session *session)
hlist_del_init(&session->hlist);
write_unlock_bh(&tunnel->hlist_lock);
- /* For L2TPv3 we have a per-net hash: remove from there, too */
- if (tunnel->version != L2TP_HDR_VER_2) {
+ /* For IP encap we have a per-net hash: remove from there, too */
+ if (tunnel->encap == L2TP_ENCAPTYPE_IP) {
struct l2tp_net *pn = l2tp_pernet(tunnel->l2tp_net);
spin_lock_bh(&pn->l2tp_session_hlist_lock);
hlist_del_init_rcu(&session->global_hlist);
next prev parent reply other threads:[~2020-01-16 12:39 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 22:34 [PATCH net] l2tp: Allow duplicate session creation with UDP Ridge Kennedy
2020-01-16 12:31 ` Tom Parkin
2020-01-16 19:28 ` Guillaume Nault
2020-01-16 21:05 ` Tom Parkin
2020-01-17 13:43 ` Guillaume Nault
2020-01-17 18:59 ` Tom Parkin
2020-01-18 17:18 ` Guillaume Nault
2020-01-16 12:38 ` Guillaume Nault [this message]
2020-01-16 13:12 ` Tom Parkin
2020-01-16 19:05 ` Guillaume Nault
2020-01-16 21:23 ` Tom Parkin
2020-01-16 21:50 ` Ridge Kennedy
2020-01-17 13:18 ` Tom Parkin
2020-01-17 14:25 ` Guillaume Nault
2020-01-17 19:19 ` Tom Parkin
2020-01-18 19:13 ` Guillaume Nault
2020-01-20 15:09 ` Tom Parkin
2020-01-21 16:35 ` Guillaume Nault
2020-01-22 11:55 ` James Chapman
2020-01-25 11:57 ` Guillaume Nault
2020-01-27 9:25 ` James Chapman
2020-01-29 11:44 ` Guillaume Nault
2020-01-30 10:28 ` James Chapman
2020-01-30 22:34 ` Guillaume Nault
2020-01-31 8:12 ` James Chapman
2020-01-31 12:49 ` Guillaume Nault
2020-01-31 9:55 ` Tom Parkin
2020-01-31 12:50 ` Guillaume Nault
2020-01-17 16:36 ` Guillaume Nault
2020-01-17 19:29 ` Tom Parkin
2020-01-18 17:52 ` Guillaume Nault
2020-01-20 11:47 ` Tom Parkin
2020-01-16 21:26 ` Ridge Kennedy
2020-01-31 12:58 ` Guillaume Nault
2020-02-03 23:29 ` Ridge Kennedy
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=20200116123854.GA23974@linux.home \
--to=gnault@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ridge.kennedy@alliedtelesis.co.nz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).