From: Siddhesh Poyarekar <siddhesh@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH] Replace potentially unsafe alloca with xmalloc/xfree in value_concat
Date: Fri, 14 Sep 2012 09:17:00 -0000 [thread overview]
Message-ID: <20120914144629.67e493d0@spoyarek> (raw)
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
Hi,
Here is another instance of an alloca that may not be safe.
The value_concat function allocates space on stack to concatenate two
strings (or duplicate a string/char/bool n times). This is not safe
because the requested space could cause alloca to move the stack
pointer beyond stack boundary. Attached patch replaces the alloca with
xmalloc/xfree.
I don't have a test case to demonstrate this, but I think the only
language this can probably be demonstrated in is ADA, a language that
I have never used. I have however verified that this does not cause any
regressions in the testsuite. OK to commit?
Regards,
Siddhesh
gdb/ChangeLog:
* valarith.c (value_concat): Replace unsafe ALLOCA with
XMALLOC/XFREE.
[-- Attachment #2: unsafe-alloca.patch --]
[-- Type: text/x-patch, Size: 1834 bytes --]
? unsafe-alloca.patch
Index: gdb/valarith.c
===================================================================
RCS file: /cvs/src/src/gdb/valarith.c,v
retrieving revision 1.105
diff -u -r1.105 valarith.c
--- gdb/valarith.c 16 Aug 2012 07:36:20 -0000 1.105
+++ gdb/valarith.c 14 Sep 2012 08:31:38 -0000
@@ -668,9 +668,11 @@
if (TYPE_CODE (type2) == TYPE_CODE_STRING
|| TYPE_CODE (type2) == TYPE_CODE_CHAR)
{
+ struct cleanup *back_to;
count = longest_to_int (value_as_long (inval1));
inval2len = TYPE_LENGTH (type2);
- ptr = (char *) alloca (count * inval2len);
+ ptr = (char *) xmalloc (count * inval2len);
+ back_to = make_cleanup (xfree, ptr);
if (TYPE_CODE (type2) == TYPE_CODE_CHAR)
{
char_type = type2;
@@ -693,6 +695,7 @@
}
}
outval = value_string (ptr, count * inval2len, char_type);
+ do_cleanups (back_to);
}
else if (TYPE_CODE (type2) == TYPE_CODE_BOOL)
{
@@ -706,6 +709,8 @@
else if (TYPE_CODE (type1) == TYPE_CODE_STRING
|| TYPE_CODE (type1) == TYPE_CODE_CHAR)
{
+ struct cleanup *back_to;
+
/* We have two character strings to concatenate. */
if (TYPE_CODE (type2) != TYPE_CODE_STRING
&& TYPE_CODE (type2) != TYPE_CODE_CHAR)
@@ -714,7 +719,8 @@
}
inval1len = TYPE_LENGTH (type1);
inval2len = TYPE_LENGTH (type2);
- ptr = (char *) alloca (inval1len + inval2len);
+ ptr = (char *) xmalloc (inval1len + inval2len);
+ back_to = make_cleanup (xfree, ptr);
if (TYPE_CODE (type1) == TYPE_CODE_CHAR)
{
char_type = type1;
@@ -737,6 +743,7 @@
memcpy (ptr + inval1len, value_contents (inval2), inval2len);
}
outval = value_string (ptr, inval1len + inval2len, char_type);
+ do_cleanups (back_to);
}
else if (TYPE_CODE (type1) == TYPE_CODE_BOOL)
{
next reply other threads:[~2012-09-14 9:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-14 9:17 Siddhesh Poyarekar [this message]
2012-09-14 11:37 ` Jan Kratochvil
2012-09-14 12:49 ` Siddhesh Poyarekar
2012-09-14 12:55 ` Jan Kratochvil
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=20120914144629.67e493d0@spoyarek \
--to=siddhesh@redhat.com \
--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