* 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.
Otherwise, I couldn't find any uses.
On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer [off-list ref] wrote:
* Arnd Bergmann:
quoted
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.