From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 332383854821; Thu, 29 Oct 2020 11:04:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 332383854821 Received: by mail-wm1-x334.google.com with SMTP id p22so895971wmg.3; Thu, 29 Oct 2020 04:04:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zcPYz8S2wXEmW4dS41Qn2A338/K8CGnPDRkKEY4clDQ=; b=PSS/Zt4KSQRTfi8HeYbn2a7chrWH1unx88m8peB7x2RCjLYVe/y1NT44aKgL9rtxi9 x9fqfX/GZR2KOkp6YnyrCpTMmiv1LVGdlqfZcjxnrh0bqWNxDkMycROoJIOT+Mk765v0 t87/oBtL75eOtN2LmrVgVuftIXcyH7Vhm0A8Nc1gR5m39vgjxouKDA9J84xc0RrQkt/w i4F3QRwVjIhWAwb8oOph6cthbuN+Jhd48Rrd6NgG0+fymsts68OMtgc57CcSHPiqNmHo TYz2U+rT25pWZ90gT/PVY7lBFq1yAfgvq6jnWGwDiFxYuEfjnr3RQk1gQ1fLIULVRFtE 0psg== X-Gm-Message-State: AOAM530R1mpbm9HKQFKO0ph3vsYJzBpzS50rXPI4usNVmGpJw5wWUHpW qjwDXTHYrjhz9hLW10O9lOk= X-Google-Smtp-Source: ABdhPJyYJNttqjwzD4T5vJ3/Y0blARIcaT4t1esjg+fT6Gfym4cbM+jsgXNMVKURDaywJYuwRkthGQ== X-Received: by 2002:a1c:2d8f:: with SMTP id t137mr3713521wmt.26.1603969455284; Thu, 29 Oct 2020 04:04:15 -0700 (PDT) Received: from [192.168.1.143] ([170.253.60.68]) by smtp.gmail.com with ESMTPSA id l16sm4460532wrx.5.2020.10.29.04.04.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 04:04:14 -0700 (PDT) Subject: Re: Possible bug in getdents64()? From: Alejandro Colomar To: libc-help@sourceware.org References: <829387c9-50d7-3d29-83bf-c4fec17cf9dd@gmail.com> Cc: linux-man , "linux-kernel@vger.kernel.org" , "libc-alpha@sourceware.org" , "Michael Kerrisk (man-pages)" Message-ID: <01065580-8602-52e6-0cca-22d1aa20a540@gmail.com> Date: Thu, 29 Oct 2020 12:04:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <829387c9-50d7-3d29-83bf-c4fec17cf9dd@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 11:04:17 -0000 [[ CC += linux-man, linux-kernel, libc-alpha, mtk ]] On 2020-10-28 20:26, Alejandro Colomar wrote: > The manual page for getdents64() says the prototype should be the > following: > >        int getdents64(unsigned int fd, struct linux_dirent64 *dirp, >                     unsigned int count); > > > Note the type of 'count': 'unsigned int' > (usually a 32-bit unsigned integer). > And the Linux kernel seems to use those types (fs/readdir.c:351): > > SYSCALL_DEFINE3(getdents64, unsigned int, fd, >         struct linux_dirent64 __user *, dirent, >         unsigned int, count) > { > ... > } > > But glibc uses 'size_t' (usually a 64-bit unsigned integer) > for the parameter 'count' (sysdeps/unix/linux/getdents64.c:25): > > > /* The kernel struct linux_dirent64 matches the 'struct dirent64' type.  */ > ssize_t > __getdents64 (int fd, void *buf, size_t nbytes) > { >   /* The system call takes an unsigned int argument, and some length >      checks in the kernel use an int type.  */ >   if (nbytes > INT_MAX) >     nbytes = INT_MAX; >   return INLINE_SYSCALL_CALL (getdents64, fd, buf, nbytes); > } > libc_hidden_def (__getdents64) > weak_alias (__getdents64, getdents64) > > > > Isn't it undefined behavior to pass a variable of a different (larger) > type to a variadic function than what it expects? > > Is that behavior defined in this implementation? > > Wouldn't a cast to 'unsigned int' be needed? > > > Thanks, > > Alex