From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D96CCC4360F for ; Mon, 18 Mar 2019 13:13:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B53C120857 for ; Mon, 18 Mar 2019 13:13:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727617AbfCRNNF convert rfc822-to-8bit (ORCPT ); Mon, 18 Mar 2019 09:13:05 -0400 Received: from albireo.enyo.de ([5.158.152.32]:56212 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726692AbfCRNNE (ORCPT ); Mon, 18 Mar 2019 09:13:04 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h5s4X-0002x0-Ef; Mon, 18 Mar 2019 13:12:57 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1h5s4X-0002Xc-CH; Mon, 18 Mar 2019 14:12:57 +0100 From: Florian Weimer To: Arnd Bergmann Cc: Deepa Dinamani , "David S . Miller" , Willem de Bruijn , alpha , linux-arch , linux-mips@vger.kernel.org, Parisc List , sparclinux , Laura Abbott , Networking , Linux Kernel Mailing List , Linux API , Josh Boyer , Linus Torvalds , Jeff Law Subject: Re: [PATCH] y2038: fix socket.h header inclusion References: <20190311153857.563743-1-arnd@arndb.de> <87k1h1fgkk.fsf@mid.deneb.enyo.de> <87a7hvded7.fsf@mid.deneb.enyo.de> <87o968y1uv.fsf@mid.deneb.enyo.de> Date: Mon, 18 Mar 2019 14:12:57 +0100 In-Reply-To: (Arnd Bergmann's message of "Mon, 18 Mar 2019 13:56:37 +0100") Message-ID: <877ecwwckm.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org * Arnd Bergmann: > On Mon, Mar 18, 2019 at 10:25 AM Florian Weimer 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. I think it is used to assert that the select family of system calls writes to the 1024 bits for each of the passed pointers. Which is not actually true—the write size is controlled by the file descriptor count argument. > 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 The footnote is missing. > 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. Please use something that is more obviously Linux-specific.