public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pmorf at apple dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/109306] New: The strstr function might do undefined behavior (out of bounds mem access) Date: Mon, 27 Mar 2023 19:24:14 +0000 [thread overview] Message-ID: <bug-109306-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306 Bug ID: 109306 Summary: The strstr function might do undefined behavior (out of bounds mem access) Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pmorf at apple dot com Target Milestone: --- Hi, I think strstr https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libiberty/strstr.c;hb=HEAD may run into undefined behavior by reading the process memory way past the end of s1. The implementation will still run memcmp even starting on the last character of s1, for the full length of s2. That also means returning null if len(s2) > len(s1) is not enough. Something along those lines would possibly work : char* strstr (const char* s1, const char* s2) { const size_t s1Len = strlen (s1); const size_t s2Len = strlen (s2); if (s1Len < s2Len) return (0); const char* const endSearchPtr = s1 + s1Len - s2Len; while (s1 <= endSearchPtr && *s1) { if (!memcmp (s1, s2, s2Len)) return s1; ++ s1; } return (0); }
next reply other threads:[~2023-03-27 19:24 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-27 19:24 pmorf at apple dot com [this message] 2023-03-27 19:27 ` [Bug other/109306] The strstr implementation in libiberty might have " pinskia at gcc dot gnu.org 2023-03-27 19:34 ` pmorf at apple dot com 2023-03-27 19:37 ` pinskia at gcc dot gnu.org 2023-03-27 19:40 ` pmorf at apple dot com 2023-03-27 19:46 ` jakub at gcc dot gnu.org 2023-03-27 19:48 ` jakub at gcc dot gnu.org 2023-04-02 18:07 ` cvs-commit at gcc dot gnu.org 2023-04-02 18:14 ` jakub at gcc dot gnu.org 2023-04-18 7:16 ` cvs-commit at gcc dot gnu.org 2023-05-02 20:16 ` cvs-commit at gcc dot gnu.org 2023-05-03 15:23 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-109306-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).