* [PATCH net-next] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function
@ 2024-03-06 9:58 Gavrilov Ilia
2024-03-06 13:14 ` Tom Parkin
0 siblings, 1 reply; 4+ messages in thread
From: Gavrilov Ilia @ 2024-03-06 9:58 UTC (permalink / raw)
To: James Chapman
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
The 'len' variable can't be negative because all 'min_t' parameters
cast to unsigned int, and then the minimum one is chosen.
To fix it, move the if statement higher.
Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
Signed-off-by: Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
---
net/l2tp/l2tp_ppp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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 *sock, int level, int optname,
if (get_user(len, optlen))
return -EFAULT;
- len = min_t(unsigned int, len, sizeof(int));
-
if (len < 0)
return -EINVAL;
+ len = min_t(unsigned int, len, sizeof(int));
+
err = -ENOTCONN;
if (!sk->sk_user_data)
goto end;
--
2.39.2
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH net-next] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function
2024-03-06 9:58 [PATCH net-next] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function Gavrilov Ilia
@ 2024-03-06 13:14 ` Tom Parkin
2024-03-06 13:46 ` Gavrilov Ilia
0 siblings, 1 reply; 4+ messages in thread
From: Tom Parkin @ 2024-03-06 13:14 UTC (permalink / raw)
To: Gavrilov Ilia
Cc: James Chapman, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
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 *sock, int level, int optname,
> if (get_user(len, optlen))
> return -EFAULT;
>
> - len = min_t(unsigned int, len, sizeof(int));
> -
> if (len < 0)
> return -EINVAL;
>
> + len = min_t(unsigned int, len, sizeof(int));
> +
> err = -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?
--
Tom Parkin
Katalix Systems Ltd
https://katalix.com
Catalysts for your Embedded Linux software development
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function
2024-03-06 13:14 ` Tom Parkin
@ 2024-03-06 13:46 ` Gavrilov Ilia
2024-03-06 14:32 ` Tom Parkin
0 siblings, 1 reply; 4+ messages in thread
From: Gavrilov Ilia @ 2024-03-06 13:46 UTC (permalink / raw)
To: Tom Parkin
Cc: James Chapman, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
On 3/6/24 16:14, Tom Parkin wrote:
> 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 *sock, int level, int optname,
>> if (get_user(len, optlen))
>> return -EFAULT;
>>
>> - len = min_t(unsigned int, len, sizeof(int));
>> -
>> if (len < 0)
>> return -EINVAL;
>>
>> + len = min_t(unsigned int, len, sizeof(int));
>> +
>> err = -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?
Thank you for answer.
In my opinion, it is better to leave the 'len' check. This way it will
be easier for the user to understand where the error is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH net-next] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function
2024-03-06 13:46 ` Gavrilov Ilia
@ 2024-03-06 14:32 ` Tom Parkin
0 siblings, 0 replies; 4+ messages in thread
From: Tom Parkin @ 2024-03-06 14:32 UTC (permalink / raw)
To: Gavrilov Ilia
Cc: James Chapman, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lvc-project@linuxtesting.org
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
On Wed, Mar 06, 2024 at 13:46:07 +0000, Gavrilov Ilia wrote:
> On 3/6/24 16:14, Tom Parkin wrote:
> > 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?
>
> Thank you for answer.
>
> In my opinion, it is better to leave the 'len' check. This way it will
> be easier for the user to understand where the error is.
Fair enough.
My concern was that in doing so we add a new behaviour which userspace
may notice and care about, but realistically I'm probably being
paranoid to imagine that any such userspace exists.
Thanks for your work on l2tp_ppp.c :-)
Reviewed-by: Tom Parkin <tparkin@katalix.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-03-06 14:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-06 9:58 [PATCH net-next] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function Gavrilov Ilia
2024-03-06 13:14 ` Tom Parkin
2024-03-06 13:46 ` Gavrilov Ilia
2024-03-06 14:32 ` Tom Parkin
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).