This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: VU#540517
- From: Bruno Haible <bruno at clisp dot org>
- To: "Robert C. Seacord" <rcs at cert dot org>
- Cc: "CERT(R) Coordination Center" <cert at cert dot org>, eggert at twinsun dot com, drepper at redhat dot com, drepper at gnu dot org, glibc-sc at gnu dot org, gcc at gcc dot gnu dot org
- Date: Fri, 2 Apr 2004 18:59:37 +0200
- Subject: Re: VU#540517
- References: <200404012003.i31K3lU1019505@starsky.blue.cert.org> <200404021352.03482.bruno@clisp.org> <406D7F6B.8030000@cert.org>
Robert C. Seacord wrote:
> However, you claim that this is not the version of __mulvsi3 etc. that
> ends up in /lib/libgcc_s.so.1? if not, in which source file do these
> versions of the functions originate?
I said that on older systems the functions from libgcc2.c end up in
/lib/libc.so.6 and on newer systems they end up in /lib/libgcc_s.so.1.
> my best thinking
> right now is that 3.3.3 and previous versions are vulnerable to integer
> overflow. could you please confirm this?
All versions of gcc <= 3.3.3 have the bug we are talking about.
However, the term "vulnerable to integer overflow" is applicable to any
software programmed in C/C++ (compiled *without* -ftrapv) or Java or similar
languages. Only languages like ANSI Common Lisp, R5RS Scheme, or
implementations that use GNU gmp, are free from integer overflow
vulnerabilities.
Btw, the impact of the bug is probably zero: I bet that on a typical Linux
system, not a single program is compiled with -ftrapv. (Try googling for
"+cflags +frapv". All occurrences that you find are commented out.)
Bruno