From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 83E0A3858C83; Sun, 24 Apr 2022 20:43:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 83E0A3858C83 From: "goldstein.w.n at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug string/29088] New: On x86_64 all versions of memrchr can segfault with seemingly valid inputs. Date: Sun, 24 Apr 2022 20:43:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: string X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: goldstein.w.n at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2022 20:43:20 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29088 Bug ID: 29088 Summary: On x86_64 all versions of memrchr can segfault with seemingly valid inputs. Product: glibc Version: 2.36 Status: UNCONFIRMED Severity: normal Priority: P2 Component: string Assignee: unassigned at sourceware dot org Reporter: goldstein.w.n at gmail dot com Target Milestone: --- ``` #define _GNU_SOURCE #include #include #include #include #include #include static __attribute__((noinline, noclone)) char * invalid_memory() { return (char *)(1UL); } #define impl memrchr int main(int argc, char ** argv) { char * buf =3D mmap(NULL, 4096 * 3, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); assert(buf !=3D MAP_FAILED); buf +=3D 4096; assert(!mprotect(buf, 4096, PROT_READ | PROT_WRITE)); uint64_t len =3D 0; uint64_t len2; int i; for (i =3D 0; i < 4096; ++i) { buf[i] =3D 1; } fprintf(stderr, "Test - 0\n"); /* Fails for SSE2, fine for AVX2/EVEX. */ assert(impl(invalid_memory(), 1, len) =3D=3D NULL); len =3D 2; fprintf(stderr, "Test - 1\n"); len2 =3D (uint64_t)buf + len - 1; /* Segfaults for SSE2, AVX2, and EVEX. */ assert(impl(invalid_memory(), 1, len2) =3D=3D impl(buf, 1, len)); } ``` The first case `Test - 0` seems like a clear bug as if length is zero readi= ng any memory is clearly outside of the "initial n bytes". The second case also appears to be a bug based on: """ This function behaves as if it reads the characters sequentially and stops = as soon as a matching character is found: if the array pointed to by ptr is smaller than count, but the match is found within the array, the behavior is well-defined """ https://en.cppreference.com/w/c/string/byte/memchr And=20 """ Implementations shall behave as if they read the memory byte by byte from t= he beginning of the bytes pointed to by s and stop at the first occurrence of c (if it is found in the initial n bytes). """ https://pubs.opengroup.org/onlinepubs/9699919799/functions/memchr.html And the description of memrchr as: """ The memrchr() function is like the memchr() function, except that it search= es backward from the end of the n bytes pointed to by s instead of forward from the beginning. """ https://linux.die.net/man/3/memchr The first potential bug in SSE2 is because there is no zero length check. The second potential bug in all implementations is because there is no page cross check if length >=3D VEC_SIZE. --=20 You are receiving this mail because: You are on the CC list for the bug.=