netdev - Re: [PATCH] l2tp: Avoid possible recursive deadlock in l2tp_tunnel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Y+KBTktdS8WLV/3/@kernel-devel>
Date:   Wed, 8 Feb 2023 01:50:22 +0900
From:   Shigeru Yoshida <syoshida@...hat.com>
To:     Guillaume Nault <gnault@...hat.com>
Cc:     jchapman@...alix.com, davem@...emloft.net, edumazet@...gle.com,
        kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] l2tp: Avoid possible recursive deadlock in
 l2tp_tunnel_register()

Hi Guillaume,

On Thu, Feb 02, 2023 at 05:43:49PM +0100, Guillaume Nault wrote:
> On Thu, Feb 02, 2023 at 12:43:49AM +0900, Shigeru Yoshida wrote:
> > Hi Guillaume,
> > 
> > On Mon, Jan 30, 2023 at 06:03:52PM +0100, Guillaume Nault wrote:
> > > On Tue, Jan 31, 2023 at 12:44:38AM +0900, Shigeru Yoshida wrote:
> > > > This patch fixes the issue by returning error when a pppol2tp socket
> > > > itself is passed.
> > > 
> > > Fixes: 0b2c59720e65 ("l2tp: close all race conditions in l2tp_tunnel_register()")
> > > 
> > > > Signed-off-by: Shigeru Yoshida <syoshida@...hat.com>
> > > > ---
> > > >  net/l2tp/l2tp_ppp.c | 7 +++++--
> > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
> > > > index db2e584c625e..88d1a339500b 100644
> > > > --- a/net/l2tp/l2tp_ppp.c
> > > > +++ b/net/l2tp/l2tp_ppp.c
> > > > @@ -702,11 +702,14 @@ static int pppol2tp_connect(struct socket *sock, struct sockaddr *uservaddr,
> > > >  			struct l2tp_tunnel_cfg tcfg = {
> > > >  				.encap = L2TP_ENCAPTYPE_UDP,
> > > >  			};
> > > > +			int dummy = 0;
> > > 
> > > There's no need to initialise dummy here. This is just confusing.
> > > We could even do without any extra variable and reuse error in
> > > sockfd_lookup().
> > > 
> > > >  			/* Prevent l2tp_tunnel_register() from trying to set up
> > > > -			 * a kernel socket.
> > > > +			 * a kernel socket.  Also, prevent l2tp_tunnel_register()
> > > > +			 * from trying to use pppol2tp socket itself.
> > > >  			 */
> > > > -			if (info.fd < 0) {
> > > > +			if (info.fd < 0 ||
> > > > +			    sock == sockfd_lookup(info.fd, &dummy)) {
> > > >  				error = -EBADF;
> > > >  				goto end;
> > > >  			}
> > > 
> > > That should work, but the real problem is calling l2tp_tunnel_register()
> > > under lock_sock(). We should instead get/create the tunnel before
> > > locking the pppol2tp socket.
> > 
> > Thank you so much for your comment, and sorry for the late response.
> > 
> > Do you mean we can call l2tp_tunnel_register() without pppol2tp socket
> > lock?
> 
> Yes. At this point, we're creating a new tunnel which is independant
> from the pppol2tp socket.
> 
> > I've read the source code of pppol2tp_connect(), but I'm not
> > sure why pppol2tp socket is locked at the beginning of this function.
> > If we can call l2tp_tunnel_register() without pppol2tp socket lock, I
> > think we can move lock_sock() after l2tp_tunnel_register().
> 
> Here are a few more details to be sure we're on the same page.
> 
> Locking the pppol2tp socket remains necessary since we access and
> modify some of its protected attributes. But we can fetch or create
> the tunnel before working on the socket. For this, the only information
> we need to get from the socket is its netns. And calling sock_net(sk)
> without holding the socket lock is fine because user space sockets
> can't have their netns modified after initialisation.
> 
> So the code for retrieving or creating the tunnel can be moved before
> the lock_sock(sk) call in pppol2tp_register(). Just make sure to adjust
> the error path accordingly. Also, a helper function might help to make
> the code more readable.

Thank you so much for the detailed explanation.  I really appreciate.
I'll think about it further, and try to prepare v2 patch.

Thanks,
Shigeru

> 
> > Thanks,
> > Shigeru
> > 
> > > 
> > 
>