public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [PATCH] [gdb/build] Fix Wstringop-truncation in coff_getfilename
Date: Wed, 26 Jul 2023 10:49:09 +0200	[thread overview]
Message-ID: <20230726084909.32090-1-tdevries@suse.de> (raw)

When building gdb with -O2 -fsanitize-threads, I ran into
a Werror=stringop-truncation.

The problem is here in coff_getfilename in coffread.c:
...
      strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
      buffer[FILNMLEN] = '\0';
...

The constant FILNMLEN is expected to designate the size of
aux_entry->x_file.x_n.x_fname, but that's no longer the case since commit
60ebc257517 ("Fixes a buffer overflow when compiling assembler for the MinGW
targets.").

Fix this by using "sizeof (aux_entry->x_file.x_n.x_fname)" instead.

Likewise in xcoffread.c.

Tested on x86_64-linux.

PR build/30669
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30669
---
 gdb/coffread.c  | 5 +++--
 gdb/xcoffread.c | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/gdb/coffread.c b/gdb/coffread.c
index 33fb2ba1fca..6ec341c61c2 100644
--- a/gdb/coffread.c
+++ b/gdb/coffread.c
@@ -1371,8 +1371,9 @@ coff_getfilename (union internal_auxent *aux_entry)
     }
   else
     {
-      strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
-      buffer[FILNMLEN] = '\0';
+      size_t x_fname_len = sizeof (aux_entry->x_file.x_n.x_fname);
+      strncpy (buffer, aux_entry->x_file.x_n.x_fname, x_fname_len);
+      buffer[x_fname_len] = '\0';
     }
   result = buffer;
 
diff --git a/gdb/xcoffread.c b/gdb/xcoffread.c
index 1538d1c823d..8930cf1bc35 100644
--- a/gdb/xcoffread.c
+++ b/gdb/xcoffread.c
@@ -1598,8 +1598,9 @@ coff_getfilename (union internal_auxent *aux_entry, struct objfile *objfile)
 		     + aux_entry->x_file.x_n.x_n.x_offset));
   else
     {
-      strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
-      buffer[FILNMLEN] = '\0';
+      size_t x_fname_len = sizeof (aux_entry->x_file.x_n.x_fname);
+      strncpy (buffer, aux_entry->x_file.x_n.x_fname, x_fname_len);
+      buffer[x_fname_len] = '\0';
     }
   return (buffer);
 }

base-commit: 477c9f2ba26ccd77016f2c97941fc8b35e332e35
-- 
2.35.3


             reply	other threads:[~2023-07-26  8:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-26  8:49 Tom de Vries [this message]
2023-07-26 13:45 ` Tom Tromey

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=20230726084909.32090-1-tdevries@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.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).