On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer <fw@xxxxxxxxxxxxx> 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.
