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);
    }

             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: link
Be 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).