On Tue, Apr 25, 2017 at 6:32 PM, David Miller <da...@davemloft.net> wrote: > From: Alexander Potapenko <gli...@google.com> > Date: Tue, 25 Apr 2017 18:27:04 +0200 > >> On Tue, Apr 25, 2017 at 5:44 PM, David Miller <da...@davemloft.net> wrote: >>> From: Alexander Potapenko <gli...@google.com> >>> Date: Mon, 24 Apr 2017 14:59:14 +0200 >>> >>>> In the case getsockopt() is called with PACKET_HDRLEN and optlen < 4 >>>> |val| remains uninitialized and the syscall may behave differently >>>> depending on its value. This doesn't have security consequences (as the >>>> uninit bytes aren't copied back), but it's still cleaner to initialize >>>> |val| and ensure optlen is not less than sizeof(int). >>>> >>>> This bug has been detected with KMSAN. >>>> >>>> Signed-off-by: Alexander Potapenko <gli...@google.com> >>>> --- >>>> v2: - if len < sizeof(int), make it 0 >>> >>> No, you should signal an error if the len is too small. >> According to manpages, only setsockopt() may return EINVAL. >> Is it ok to change the behavior of getsockopt() to return EINVAL in >> this case? (I.e. won't we break existing users that don't expect it?) > > They are currently getting corrupt data depending upon the endianness, > so -EINVAL is a serious improvement. On a second glance getsockopt() already returns -EINVAL in some cases, so man is already imprecise.
-- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
