[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1DzRhiuNxBeQaTYSX1NhCaN6+B0Ya7aeGfxUGj35LFhw@mail.gmail.com>
Date: Mon, 18 Mar 2019 13:56:37 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Deepa Dinamani <deepa.kernel@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Willem de Bruijn <willemb@...gle.com>,
alpha <linux-alpha@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
linux-mips@...r.kernel.org,
Parisc List <linux-parisc@...r.kernel.org>,
sparclinux <sparclinux@...r.kernel.org>,
Laura Abbott <labbott@...hat.com>,
Networking <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
Josh Boyer <jwboyer@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jeff Law <law@...hat.com>
Subject: Re: [PATCH] y2038: fix socket.h header inclusion
On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer <fw@...eb.enyo.de> wrote:
>
> * Arnd Bergmann:
>
> > Should we just remove __kernel_fd_set from the exported headers and
> > define the internal fd_set directly in include/linux/types.h? (Adding the
> > folks from the old thread to Cc).
>
> The type is used in the sanitizers, but incorrectly. They assume that
> FD_SETSIZE is always 1024. (The existence of __kernel_fd_set is
> itself somewhat questionable because it leads to such bugs.)
> Moving around the type could cause a build failure in the sanitizers, but I'm
> not entirely clear how the UAPI headers are included there.
It looks like sanitizer_platform_limits_posix.cc includes
linux/posix_types.h to ensure that __kernel_fd_set is the same
size as __sanitizer___kernel_fd_set, and then it uses the
latter afterwards.
What I don't see here is what kind of operation is actually done
on the data, I only see a cast to void. If libsanitizer actually does
anything interesting here, we should definitely fix it to use the
correct size, especially since this is actually something that
can trigger a buffer overflow in subtle ways when used carelessly.
See for example [1], which we still have not addressed
(I suspect we actually need to have glibc use __kernel_long_t
instead of 'long int' here, but that is a separate issue, and
not overly important given how few users there are on x32).
For this specific use (and probably others like it), renaming the
fds_bits member to __kernel_fds_bits or something like that
would keep user space still compiling. That would only break
if someone was using __kernel_fd_set, and actually doing
bit operations on it. glibc uses '__fds_bits' unless __USE_XOPEN
is set, so maybe we should use use that name unconditionally.
> Otherwise, I couldn't find any uses.
Powered by blists - more mailing lists