From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id E675C25914 for ; Sat, 22 Jun 2024 21:35:44 +0200 (CEST) Received: (qmail 13703 invoked by uid 550); 22 Jun 2024 19:35:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30664 invoked from network); 22 Jun 2024 18:37:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719081464; x=1719686264; darn=lists.openwall.com; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=29ssb1Avo1YLOtgRK1piPyx1KLA0GbKERHRZ2d3DCMs=; b=hEPftkHGP2sNfD/RRcNXWhlMWcjZOWx2VWoRpM+GZ5GecXmIB9xVyTIwtfR9oA1pmy EmazpszwaHibDSt7Ute6McqBdzojRAjzWA6Pm++ECbjcaj03gXxBj+2fMkKoIFEv6INx 5Pp9JS1a2i0wdOzuPDx1mnIs2SXYHANdHV1mbC+512SQ8U1JoiSP3RccKh0nQHgm4OcJ iaI1oVxd7IF/riL2FR3xut91h9mOuhzzc+QPAVgDDeGb8MP35wn+McGJe0ILqjau9z8a kz5/kDQ3Qu8lxqLggxTJpF8XdvdYDZ+fCdJo9NI2uW/O4qNW1Q1xJAxgy5FIBErmh6nv L2dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719081464; x=1719686264; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=29ssb1Avo1YLOtgRK1piPyx1KLA0GbKERHRZ2d3DCMs=; b=b2b8oAM598JiPvjWPfVuvImJTxR6paQjrouKJqv+hBRQ8vQMr+YJc4Ho7rFqShPHhk aMeyc6SzzCQgM6s0mLrEPMaO+VqpPxZjuhrsuev8f4RoWB0l4o2V05a+8Bx3iruMJcu1 88pL02m6Naf6xfdVNk8vxLKdBBvMycsEOw6FDcAsBxOeRyff7Xh84sVLQoDgiRmGqE1R 2ujyfBqwSYqZGbpyJJ18FvSkMVnLDBBiSxbjuqneNnwuQ/HFOF0PXLg0c9YPYIQVEv/x PHpNpM1QeNbu5jdDG9t+bd6nRD/0qBbDabBnVd8cakNfvDWu/VJI2dOaMjCUZ1hSY3xv 46Tg== X-Gm-Message-State: AOJu0YxJ7+/wV7ZTWz7LeeQtxyalIhKWb/ZWS+vP8KH8G5laZvJXjRsn FZ8rUGf7LewS4vSmCtkI4LX8Y0zwhP3x4vIyHk3xfNLd5LGIFp/4y0mP+o1z02k= X-Google-Smtp-Source: AGHT+IFMY9jX02bq1WfjWAbe3YsCTO53fhcX5YlMdn6rIvR5tVEueV403Yf+mVYq8a2vQZL7eNBQww== X-Received: by 2002:a17:906:ba8b:b0:a6f:b3d3:fed1 with SMTP id a640c23a62f3a-a70275f2935mr136584766b.10.1719081463402; Sat, 22 Jun 2024 11:37:43 -0700 (PDT) From: Florian Ziesche Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_90243F4F-43BE-4A87-995F-A5B4D90B04F4" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Date: Sat, 22 Jun 2024 20:37:31 +0200 In-Reply-To: <20240622010600.GC10433@brightrain.aerifal.cx> Cc: musl@lists.openwall.com To: Rich Felker References: <20240523202803.GC10433@brightrain.aerifal.cx> <20240622010600.GC10433@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.3774.600.62) Subject: Re: [musl] [PATCH] dynlink: fix get_lfs64() with posix_fallocate64 --Apple-Mail=_90243F4F-43BE-4A87-995F-A5B4D90B04F4 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Yep, this works for me. > On 22. Jun 2024, at 03:06, Rich Felker wrote: > > On Thu, May 23, 2024 at 04:28:03PM -0400, Rich Felker wrote: >> On Fri, May 10, 2024 at 06:01:58PM +0200, Florian Ziesche wrote: >>> Hi, >>> >>> this patch increases the buffer size by one in get_lfs64() so that it >>> works with posix_fallocate64. >>> "posix_fallocate64" is 17 characters long, so 16 is one too short. >>> >>> Simplified example: >>> before: https://compiler-explorer.com/z/4qcPhcaWr >>> after: https://compiler-explorer.com/z/scGvhddKW >>> >>> --- >>> diff --git a/ldso/dynlink.c b/ldso/dynlink.c >>> index 42687da2..8707ae1c 100644 >>> --- a/ldso/dynlink.c >>> +++ b/ldso/dynlink.c >>> @@ -363,7 +363,7 @@ static struct symdef get_lfs64(const char *name) >>> "stat\0statfs\0statvfs\0tmpfile\0truncate\0versionsort\0" >>> "__fxstat\0__fxstatat\0__lxstat\0__xstat\0"; >>> size_t l; >>> - char buf[16]; >>> + char buf[17]; >>> for (l=0; name[l]; l++) { >>> if (l >= sizeof buf) goto nomatch; >>> buf[l] = name[l]; >> >> Thanks for catching this. I questioned whether the 17 is sufficient, >> but indeed the buffer is never nul terminated except when removing the >> 64, so it should be ok. >> >> I think I'll apply your patch as a direct fix, but the whole copying >> operation is unnecessary and I'll probably remove it. It works just as >> well to strncmp and pass p instead of buf to find_sym, so that a >> mutable copy of the name to lookup is never needed. > > Applied. Does the attached look ok to get rid of the copy entirely? It > passed basic smoke testing here. > > --Apple-Mail=_90243F4F-43BE-4A87-995F-A5B4D90B04F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yep, this = works for me.

On 22. Jun 2024, at 03:06, Rich Felker = <dalias@libc.org> wrote:

On Thu, May 23, 2024 at 04:28:03PM -0400, = Rich Felker wrote:
On Fri, May 10, 2024 at 06:01:58PM +0200, = Florian Ziesche wrote:
Hi,

this = patch increases the buffer size by one in get_lfs64() so that = it
works with posix_fallocate64.
"posix_fallocate64" is 17 = characters long, so 16 is one too short.

Simplified = example:
before: https://compiler-explorer.com/z/4qcPhcaWr
after: = https://compiler-explorer.com/z/scGvhddKW

---
diff --git = a/ldso/dynlink.c b/ldso/dynlink.c
index 42687da2..8707ae1c = 100644
--- a/ldso/dynlink.c
+++ b/ldso/dynlink.c
@@ -363,7 = +363,7 @@ static struct symdef get_lfs64(const char = *name)
        "stat\0statfs\0s= tatvfs\0tmpfile\0truncate\0versionsort\0"
     = ;   "__fxstat\0__fxstatat\0__lxstat\0__xstat\0";
 &= nbsp;  size_t l;
-    char buf[16];
+ =    char buf[17];
    for (l=3D0; = name[l]; l++) {
        if (l = >=3D sizeof buf) goto = nomatch;
        buf[l] =3D = name[l];

Thanks for catching this. I questioned = whether the 17 is sufficient,
but indeed the buffer is never nul = terminated except when removing the
64, so it should be ok.

I = think I'll apply your patch as a direct fix, but the whole = copying
operation is unnecessary and I'll probably remove it. It = works just as
well to strncmp and pass p instead of buf to find_sym, = so that a
mutable copy of the name to lookup is never = needed.

Applied. Does the attached look ok to get rid of the copy = entirely? It
passed basic smoke = testing here.

<get_lfs64.diff>

= --Apple-Mail=_90243F4F-43BE-4A87-995F-A5B4D90B04F4--