From nobody Sat Sep 16 04:23:32 2023 X-Original-To: dev-commits-src-main@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 4RndGY2w5cz4smBD; Sat, 16 Sep 2023 04:23:33 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RndGY0RZNz4bgV; Sat, 16 Sep 2023 04:23:33 +0000 (UTC) (envelope-from git@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1694838213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/8th/LDc9pWq9zDnwk97wjBli/u+49Au75i0yCgrUSA=; b=mcncSohkY4RxD1vSD4ah46hyuXI9abLJjRCmpgUXaATNv20UXXBPvhMjCRWSZA3X6Q3yJ+ f9dy4kDRw/zOeCFFb1vDwEYCXIYvqCuwhtMNjDzFFtPcGlW51e9mZIn+Kr+C0zGZlD4BDx egjXjfGoDAgHtsIHEFMfgS47fIQdMQfTV8qXdTXScG+OnoxnmuTHpmqtbHOZepJvyhIIA8 oBoSHGF/a0UwExYVSSVwmgYSDk2mhnGNGP0Z/CcAIdmI93Pj3szNfjlfc1e7OZSL/xwE+4 ECxVO3eipO1mernjarsmWpE/zNE5i1wt+ihuw8CXgKDwqrQU9DsLg6+WCrD0Jg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1694838213; a=rsa-sha256; cv=none; b=m2sDc3qoOegViJwP45spl30Bt1TaNKVePU7M3772gfO9+WFqi8ZiAtZPIsRhTBpkHIkY6H 0To40peYlW1YGzcaBwlZVDkOSVCrL2oiQ420laae0uCjq8Px2hmoKgLa/13SrT+F28Qwrn Y/PopVijXMU5PjQpN3X3yumIztx7sHXcilWIDN3os3JKuyh1UhgsHJBaIimLUdgx1cgh85 K2/k6NHX8ed/VBJugilO1eP6mn6wbIhrTand8Flg2g/8YCL6oqblCcjNuLRizIf3ic1+yj SgHmq8iRt0M+kZIbRvmALvB3F+u4xOLkEon9pW/H1o1U/frloPcsCo93g3py2A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1694838213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/8th/LDc9pWq9zDnwk97wjBli/u+49Au75i0yCgrUSA=; b=IcMOFkRmNcmMz9V+rkK/583D7h8bWgAKCAFds7/ZjUg8lTMludD0whH4xzCqEpaFHbOnTG YGbmcvu8JR/p434BSY/v1T2gJgVABtZsRoiS2dcWnL9cP6TnmFkGvWiTqlv8aRgwqh6WWJ DuOPNP+VZVuH566w4J2tLTGkZNKIrqGjJEDQLW6Cjo7/RzVuY3tZWKZou9f+JIrziLtoV4 mWTV8034AXZv8v4QMw09qtdMzKpCDfMZDTCx6+hr2UC69Bk/obpSMNnA7Ps+kPhNfCOFvf gt4j1XQb+30Vkr1qa2nOXSL+Uppld7bl48cdwnNf6CmOSgDcj49irFE/t1MiCQ== Received: from gitrepo.freebsd.org (gitrepo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:5]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4RndGX6HwBzsfF; Sat, 16 Sep 2023 04:23:32 +0000 (UTC) (envelope-from git@FreeBSD.org) Received: from gitrepo.freebsd.org ([127.0.1.44]) by gitrepo.freebsd.org (8.17.1/8.17.1) with ESMTP id 38G4NWSA019461; Sat, 16 Sep 2023 04:23:32 GMT (envelope-from git@gitrepo.freebsd.org) Received: (from git@localhost) by gitrepo.freebsd.org (8.17.1/8.17.1/Submit) id 38G4NW9A019458; Sat, 16 Sep 2023 04:23:32 GMT (envelope-from git) Date: Sat, 16 Sep 2023 04:23:32 GMT Message-Id: <202309160423.38G4NW9A019458@gitrepo.freebsd.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org From: Robert Clausecker Subject: git: 953b93cf24d8 - main - lib/libc/amd64/string/memcmp.S: harden against phony buffer lengths List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Git-Committer: fuz X-Git-Repository: src X-Git-Refname: refs/heads/main X-Git-Reftype: branch X-Git-Commit: 953b93cf24d8871c62416c9bcfca935f1f1853b6 Auto-Submitted: auto-generated The branch main has been updated by fuz: URL: https://cgit.FreeBSD.org/src/commit/?id=953b93cf24d8871c62416c9bcfca935f1f1853b6 commit 953b93cf24d8871c62416c9bcfca935f1f1853b6 Author: Robert Clausecker AuthorDate: 2023-09-14 05:19:01 +0000 Commit: Robert Clausecker CommitDate: 2023-09-16 04:20:32 +0000 lib/libc/amd64/string/memcmp.S: harden against phony buffer lengths When memcmp(a, b, len) (or equally, bcmp) is called with a phony length such that a + len < a, the code would malfunction and not compare the two buffers correctly. While such arguments are illegal (buffers do not wrap around the end of the address space), it is neverthless conceivable that people try things like memcmp(a, b, SIZE_MAX) to compare a and b until the first mismatch, in the knowledge that such a mismatch exists, expecting memcmp() to stop comparing somewhere around the mismatch. While memcmp() is usually written to confirm to this assumption, no version of ISO/IEC 9899 guarantees this behaviour (in contrast to memchr() for which it is). Neverthless it appears sensible to at least not grossly misbehave on phony lengths. This change hardens memcmp() against this case by comparing at least until the end of the address space if a + len overflows a 64 bit integer. Sponsored by: The FreeBSD Foundation Approved by: mjg (blanket, via IRC) See also: b2618b651b28fd29e62a4e285f5be09ea30a85d4 MFC after: 1 week --- lib/libc/amd64/string/memcmp.S | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/lib/libc/amd64/string/memcmp.S b/lib/libc/amd64/string/memcmp.S index d192229677b3..dc8bcff73cb9 100644 --- a/lib/libc/amd64/string/memcmp.S +++ b/lib/libc/amd64/string/memcmp.S @@ -328,13 +328,28 @@ ARCHENTRY(memcmp, baseline) movdqu 16(%rsi, %rdi, 1), %xmm1 pcmpeqb 16(%rdi), %xmm1 # compare second half of this iteration add %rcx, %rdx # pointer to last byte in buffer - pcmpeqb %xmm2, %xmm0 + jc .Loverflow # did this overflow? +0: pcmpeqb %xmm2, %xmm0 pmovmskb %xmm0, %eax xor $0xffff, %eax # any mismatch? jne .Lmismatch_head add $64, %rdi # advance to next iteration jmp 1f # and get going with the loop + /* + * If we got here, a buffer length was passed to memcmp(a, b, len) + * such that a + len < a. While this sort of usage is illegal, + * it is plausible that a caller tries to do something like + * memcmp(a, b, SIZE_MAX) if a and b are known to differ, intending + * for memcmp() to stop comparing at the first mismatch. This + * behaviour is not guaranteed by any version of ISO/IEC 9899, + * but usually works out in practice. Let's try to make this + * case work by comparing until the end of the address space. + */ +.Loverflow: + mov $-1, %rdx # compare until the end of memory + jmp 0b + /* process buffer 32 bytes at a time */ ALIGN_TEXT 0: movdqu -32(%rsi, %rdi, 1), %xmm0