From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32339 invoked by alias); 2 Apr 2004 17:05:49 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32316 invoked from network); 2 Apr 2004 17:05:42 -0000 Received: from unknown (HELO ftp.ilog.fr) (81.80.162.195) by sources.redhat.com with SMTP; 2 Apr 2004 17:05:42 -0000 Received: from laposte.ilog.fr (cerbere-qe0 [81.80.162.193]) by ftp.ilog.fr (8.12.11/8.12.11) with ESMTP id i32H5a8m011302; Fri, 2 Apr 2004 19:05:36 +0200 (MET DST) Received: from honolulu.ilog.fr ([172.16.15.122]) by laposte.ilog.fr (8.12.10/8.12.10) with ESMTP id i32H5Zhc020750; Fri, 2 Apr 2004 19:05:35 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by honolulu.ilog.fr (Postfix) with ESMTP id 5D4363B3B2; Fri, 2 Apr 2004 16:59:38 +0000 (UTC) From: Bruno Haible To: "Robert C. Seacord" Subject: Re: VU#540517 Date: Fri, 02 Apr 2004 17:05:00 -0000 User-Agent: KMail/1.5 Cc: "CERT(R) Coordination Center" , eggert@twinsun.com, drepper@redhat.com, drepper@gnu.org, glibc-sc@gnu.org, gcc@gcc.gnu.org References: <200404012003.i31K3lU1019505@starsky.blue.cert.org> <200404021352.03482.bruno@clisp.org> <406D7F6B.8030000@cert.org> In-Reply-To: <406D7F6B.8030000@cert.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404021859.37220.bruno@clisp.org> X-SW-Source: 2004-04/txt/msg00129.txt.bz2 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