[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <01ec9cbaedbd4d91976d10308b7b8e2d@AcuMS.aculab.com>
Date: Fri, 12 Apr 2024 17:23:10 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Eric Dumazet' <edumazet@...gle.com>, "David S . Miller"
<davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>
CC: Simon Horman <horms@...nel.org>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, "eric.dumazet@...il.com" <eric.dumazet@...il.com>
Subject: RE: [PATCH net 0/3] net: start to replace copy_from_sockptr()
From: Eric Dumazet
> Sent: 08 April 2024 09:29
>
> We got several syzbot reports about unsafe copy_from_sockptr()
> calls. After fixing some of them, it appears that we could
> use a new helper to factorize all the checks in one place.
>
> This series targets net tree, we can later start converting
> many call sites in net-next.
I have wondered if 'sockptr' should be changed to include the
length and then passed by reference.
That would work 'readonly' for most code, but there are some strange
options that don't obey the expected rules.
At least one has a 'record count' in the 'normal' buffer and the
rest of the data follows - an accident waiting to happen
(especially if called by bpf).
I must find time to prod the bpf people about changing sockptr_t
to be a struct instead of a union - also safer.
The other obvious change is to pull the usercopy for the length
all the way out of getsockopt() to the syscall wrapper.
I started writing a patch to use the return value for the updated
length - but some of the code is too perverted.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists