From nobody Tue Dec 16 19:33:32 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dW6YD5wXsz6L2gS; Tue, 16 Dec 2025 19:33:36 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dW6YD5PP1z3glT; Tue, 16 Dec 2025 19:33:36 +0000 (UTC) (envelope-from rpokala@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1765913616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rzLViezmAx0B5FHtRcjMnoh6af6GcEiRaAYs1/zrB6M=; b=VIoYo0VBMxJSacap2qq2U6HMvg0y6+ho9gqU/5RQeEtc2a6r4CIrj0Xx30NZPUbrgmEN1r w96Clyp15Di8B6d7AivD5hMl/QXAzyx+GtoSS0s2Ld5F3mrvtvmtdCCcNrKiQcps14c7WA E8DiXDKX6LFNrnT68ujVj1CJHmihYRDT0tce5Fso2gzjLhcO+BzI5a5D1cD5ofLwb7rsE+ 4TEAcFKXkgEwLNfz+OlVLJ3fmByYwuqtXyil2noKj8HzKnq5ACrbmdiD0F0R4XayhmjurR 8vdaM604lMo/y4KfN/OQWZGmyL/ThCqmNkMZRIRLqG6HzJZO5diUbNV0blSrvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1765913616; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rzLViezmAx0B5FHtRcjMnoh6af6GcEiRaAYs1/zrB6M=; b=goN1Npq7AQMegDuMJ6afTleHBMvWREotMLKzcJuUKWQ1avo5rEo/ermS2otABngjbOJ0zp T24ZHdPBJRLQQUXJ4znuLdT3XjMra5cmYWdJepbdvrEeLufmLoYTVcxllUVjDEpspeJBS0 OKq6xL1wHQecALCqGhKm2KhcYP0R74zPW2LkPIOlHV5/T+EfIsc3CMCLU72VyMRyJwqMeq WEH6RBm7TgmWJfcelKcAz0HP2CQwBmesHuE/rMTj+mruWKCN0LSaANazZGtrsckz6YiMK4 sVqY6z8B7rmD8o7qEAebvrWyWO48SiZ/xnzrGmFACTDxtnz66uSICP5c6lDa8g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1765913616; a=rsa-sha256; cv=none; b=J0V3EE+FMl/fZnSG6opabIxFjAfg39QlywEqHoLIcYmHdjS2rgoKurxWuRwfvgMQoP77IO 8f88Q+g+32Rgwn1FEMLSWsPdGlD8H/SH7sajjE4cHeSRWnnQEdvpp68mWiBEE5PXjkULmo 3ETDhyJmaPntL2KjOn77oVNGXOi+qM2DgTcMPs0SgVLUR+a29FFqLjqh4jS+ELn3cUK13y sj8NmDi+Pf5+PB/vliytnTVzwSpMUixb/ziNCgu/pI9w7OGC+tu2s8Oev9v1PWuMvnRN4t z4D6Z8CpiAj1xlWVVnqfmuK6zjQXsqWTHQLgeAVVeZ4QiQN7Kdugs2ltrcYd9A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [172.17.5.105] (dip-pa.panasas.com [65.205.22.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 4dW6YD0tH6z1bN; Tue, 16 Dec 2025 19:33:36 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/16.103.25120717 Date: Tue, 16 Dec 2025 14:33:32 -0500 Subject: Re: 66eb78377bf1 - main - libc/amd64: fix overread conditions in stpncpy() From: Ravi Pokala To: Cy Schubert CC: Robert Clausecker , , , Message-ID: Thread-Topic: 66eb78377bf1 - main - libc/amd64: fix overread conditions in stpncpy() References: <693ee0f1.3662d.650a5e21@gitrepo.freebsd.org> <20251216135709.46D25203@slippy.cwsent.com> <20251216160002.A65D63D6@slippy.cwsent.com> In-Reply-To: <20251216160002.A65D63D6@slippy.cwsent.com> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I know ~nothing of assembly, but one thing that seems odd to me is that the= 'bts' line originally used '%r8d', but the new version uses '%r8'. And yet,= the new 'test' line uses '%r8d'. Again, knowing nothing about this, it seem= s to me that the 'bts' and 'test' should probably be talking about the same = thing...? -Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: > on behalf of Cy Schubert > Reply-To: Cy Schubert > Date: Tuesday, December 16, 2025 at 11:00 To: Cy Schubert > Cc: Robert Clausecker >, >, >, > Subject: Re: git: 66eb78377bf1 - main - libc/amd64: fix overread conditions= in stpncpy() In message <20251216135709.46D25203@slippy.cwsent.com >, Cy Schubert writes: > In message <693ee0f1.3662d.650a5e21@gitrepo.freebsd.org >, Robert Clausecker=20 > wri > tes: > > The branch main has been updated by fuz: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=3D66eb78377bf109af1d9e25626b= f254 > b4 > > 369436ec > > > > commit 66eb78377bf109af1d9e25626bf254b4369436ec > > Author: Robert Clausecker > > > AuthorDate: 2025-12-10 20:45:18 +0000 > > Commit: Robert Clausecker > > > CommitDate: 2025-12-14 16:06:05 +0000 > > > > libc/amd64: fix overread conditions in stpncpy() > >=20 > > Due to incorrect unit test design, two overread conditions went > > undetected in the amd64 baseline stpncpy() implementation. > > For buffers of 1--16 and 32 bytes that do not contain nul bytes > > and end exactly at a page boundary, the code would incorrectly > > read 16 bytes from the next page, possibly crossing into an > > unmapped page and crashing the program. If the next page was > > mapped, the code would then proceed with the expected behaviour > > of the stpncpy() function. > >=20 > > Three changes were made to fix the bug: > >=20 > > - an off-by-one error is fixed in the code deciding whether to > > enter the runt case or not, entering it for 0 > instead of 0 > - in the runt case, the logic to skip reading a second 16-byte > > chunk if the buffer ends in the first chunk was fixed to > > account for buffers that end at a 16-byte boundary but do not > > hold a nul byte. > > - in the runt case, the logic to transform the location of the > > end of the input buffer into a bit mask was fixed to allow > > the case of n=3D=3D32, which was previously impossible due to the > > incorrect logic for entering said case. > >=20 > > The performance impact should be minimal. > >=20 > > PR: 291359 > > See also: D54169 > > Reported by: Collin Funk > > > Reviewed by: getz > > Approved by: markj (mentor) > > MFC after: 1 week > > Fixes: 90253d49db09a9b1490c448d05314f3e4bbfa468 (D42519) > > Differential Revision: https://reviews.freebsd.org/D54170 > > --- > > lib/libc/amd64/string/stpncpy.S | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/lib/libc/amd64/string/stpncpy.S b/lib/libc/amd64/string/st= pncp > y. > > S > > index 5ce0dd093a9e..df22bb9f0c53 100644 > > --- a/lib/libc/amd64/string/stpncpy.S > > +++ b/lib/libc/amd64/string/stpncpy.S > > @@ -100,7 +100,7 @@ ARCHENTRY(__stpncpy, baseline) > > movdqa (%rsi), %xmm0 # load head > > and $0xf, %ecx # offset from alignment > > mov $-1, %r9d > > - lea -32(%rcx), %rax # set up overflow-proof compari > > son rdx+rcx<=3D32 > > + lea -33(%rcx), %rax # set up overflow-proof compari > > son rdx+rcx<=3D32 > > shl %cl, %r9d # mask of bytes belonging to th > > e string > > sub %rcx, %rdi # adjust RDI to correspond to R > > SI > > pxor %xmm1, %xmm1 > > @@ -223,8 +223,9 @@ ARCHENTRY(__stpncpy, baseline) > >=20 > > /* 1--32 bytes to copy, bounce through the stack */ > > .Lrunt: movdqa %xmm1, bounce+16(%rsp) # clear out rest of on- > > stack copy > > - bts %r10d, %r8d # treat end of buffer as end of > > string > > - and %r9w, %r8w # end of string within first bu > > ffer? > > + bts %r10, %r8 # treat end of buffer as end of > > string > > + and %r9d, %r8d # mask out head before string > > + test $0x1ffff, %r8d # end of string within first ch > > unk or right after? > > jnz 0f # if yes, do not inspect second > > buffer > >=20 > > movdqa 16(%rsi), %xmm0 # load second chunk of input > > > > I've opened PR/291720 regarding a significant regression caused by this=20 > commit. It affects my older machines, resulting in enviornment (getenv)=20 > corruption. It does not affect my newer (and with more RAM) machines. BTW, this brought my postfix server effectively offline. I have not been=20 able to send or receive email until this commit was reverted locally. --=20 Cheers, Cy Schubert > FreeBSD UNIX: > Web: https://FreeBSD= .org NTP: > Web: https://nwtime.org e**(i*pi)+1=3D0