Received-SPF: pass (google.com: domain of linux-kernel+bounces-93966-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 6 Mar 2024 13:14:23 +0000
From: Tom Parkin <tparkin@katalix.com>
To: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
Cc: James Chapman <jchapman@katalix.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lvc-project@linuxtesting.org" <lvc-project@linuxtesting.org>
Subject: Re: [PATCH net-next] l2tp: fix incorrect parameter validation in the
 pppol2tp_getsockopt() function
Message-ID: <ZehsL8sHd3vgplv1@katalix.com>
References: <20240306095449.1782369-1-Ilia.Gavrilov@infotecs.ru>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="sRqq1QTNgT2eAlVi"
Content-Disposition: inline
In-Reply-To: <20240306095449.1782369-1-Ilia.Gavrilov@infotecs.ru>


--sRqq1QTNgT2eAlVi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On  Wed, Mar 06, 2024 at 09:58:10 +0000, Gavrilov Ilia wrote:
> diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
> index f011af6601c9..6146e4e67bbb 100644
> --- a/net/l2tp/l2tp_ppp.c
> +++ b/net/l2tp/l2tp_ppp.c
> @@ -1356,11 +1356,11 @@ static int pppol2tp_getsockopt(struct socket *soc=
k, int level, int optname,
>  	if (get_user(len, optlen))
>  		return -EFAULT;
> =20
> -	len =3D min_t(unsigned int, len, sizeof(int));
> -
>  	if (len < 0)
>  		return -EINVAL;
> =20
> +	len =3D min_t(unsigned int, len, sizeof(int));
> +
>  	err =3D -ENOTCONN;
>  	if (!sk->sk_user_data)
>  		goto end;

I think this code in l2tp_ppp.c has probably been inspired by a
similar implementations elsewhere in the kernel -- for example
net/ipv4/udp.c udp_lib_getsockopt does the same thing, and apparently
has been that way since the dawn of git time.

I note however that plenty of other getsockopt implementations which
are using min_t(unsigned int, len, sizeof(int)) don't check the length
value at all: as an example, net/ipv6/raw.c do_rawv6_getsockopt.

As it stands right now in the l2tp_ppp.c code, I think the check on
len will end up doing nothing, as you point out.

So moving the len check to before the min_t() call may in theory
possibly catch out (insane?) userspace code passing in negative
numbers which may "work" with the current kernel code.

I wonder whether its safer therefore to remove the len check
altogether?
--=20
Tom Parkin
Katalix Systems Ltd
https://katalix.com
Catalysts for your Embedded Linux software development

--sRqq1QTNgT2eAlVi
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEsUkgyDzMwrj81nq0lIwGZQq6i9AFAmXobCoACgkQlIwGZQq6
i9CJ3ggAnMVBtH7FFAb+vH6t/MidRzhvkMZ4t9DE5Tt3WOwm1aN2YKKsvuUdzR5f
32KbhH2EI2S8uEqwJBNwl5+rZ1QWmPFHdL62N0yW3juzR9K64+WpXGeGmdIFZXgS
R0J7b0u/GvsWleVV/HNuqrMCnAxSxAs9f9FKrcyqx2zsFsi2P3cwpsbEaXOsdnkM
W7yeGoDbx9J2BkWp9OdItzhv8y+ecb6CtgbGMVHDC7/iL3A+P9bgZqh/BFfON+s1
IDmtSE0OJFYb3KgQLxMAybXe4B+w7jyWKcCpu30cEOwSd9waDJotoeTOktINyLSb
8mpupV5PgGYvZzgSZ1IVQ25fZKel/w==
=7U9S
-----END PGP SIGNATURE-----

--sRqq1QTNgT2eAlVi--