This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: mem stomp in cpplib.c?
- To: Robert Lipe <robertl at sco dot com>, Andreas Jaeger <aj at suse dot de>
- Subject: Re: mem stomp in cpplib.c?
- From: Zack Weinberg <zack at wolery dot cumb dot org>
- Date: Wed, 5 Jul 2000 09:35:35 -0700
- Cc: gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- References: <20000705102250.T22747@rjlhome.sco.com>
On Wed, Jul 05, 2000 at 10:22:50AM -0500, Robert Lipe wrote:
> This results in cpp coring:
>
> $ > /tmp/x.c
> $ ./cpp -Amachine\(i386\) -Acpu\(i386\) /tmp/x.c
>
> The offending code looks to be in cpplib.c:1330.
>
> *answerp = answer;
> len = predicate->val.name.len + 1;
> sym = alloca (len);
>
> /* Prefix '#' to get it out of macro namespace. */
> sym[0] = '#';
> memcpy (sym + 1, predicate->val.name.text, len);
> return cpp_lookup (pfile, sym, len);
>
> error:
>
>
> 'sym' holds 'len' bytes of storage. We then copy 'len' bytes of storage
> starting at 'sym+1'. So we have a tiny little stack overwrite here.
Yes. Also reported by Andreas Jaeger, over on gcc-bugs. This is my
candidate patch - I can't reproduce the problem on my system, so can
you test it, please?
zw
* cpplib.c (_cpp_parse_assertion): Fix buffer overrun.
===================================================================
Index: cpplib.c
--- cpplib.c 2000/07/05 05:33:56 1.181
+++ cpplib.c 2000/07/05 16:34:26
@@ -1322,8 +1322,8 @@ _cpp_parse_assertion (pfile, answerp)
lookup_node:
*answerp = answer;
- len = predicate->val.name.len + 1;
- sym = alloca (len);
+ len = predicate->val.name.len;
+ sym = alloca (len + 1);
/* Prefix '#' to get it out of macro namespace. */
sym[0] = '#';