From owner-freebsd-current@FreeBSD.ORG Fri May 28 08:37:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7081F16A4CE for ; Fri, 28 May 2004 08:37:46 -0700 (PDT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F3F843D2D for ; Fri, 28 May 2004 08:37:45 -0700 (PDT) (envelope-from wjw@withagen.nl) Received: from dual (dual [212.61.27.71]) by freebee.digiware.nl (8.12.10/8.12.10) with SMTP id i4SFWp67093363; Fri, 28 May 2004 17:32:58 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <08dc01c444c9$18703aa0$471b3dd4@dual> From: "Willem Jan Withagen" To: "Bruce Evans" References: <074501c44449$3ab41bc0$471b3dd4@dual><20040528011551.GB48226@xor.obsecurity.org> <077001c44486$ddd75640$471b3dd4@dual> <079001c444bf$830965d0$471b3dd4@dual> <20040529005036.N15392@gamplex.bde.org> Date: Fri, 28 May 2004 17:33:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 cc: freebsd-current@freebsd.org Subject: Re: Possible bug in malloc-code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2004 15:37:46 -0000 > If a section is larger than INT_MAX, then overflow seems to occur here > in __elfN_coredump(): > > % for (i = 0; i < seginfo.count; i++) { > % error = vn_rdwr_inchunks(UIO_WRITE, vp, > % (caddr_t)php->p_vaddr, php->p_filesz, offset, > ^^^^^^^^^^^^^ > % UIO_USERSPACE, IO_DIRECT, cred, NOCRED, NULL, td); > > php->p_filesz has type u_int64_t on 64-bit machines, but here it gets > silently converted to int, so it overflows if the size is larger than > INT_MAX. (Overflow may occur even on 32-bit machines, but it's harder > to fit a section larger than INT_MAX on a 32-bit machine.) If ints > are 32-bits 2's complement and the section size is between 2^31 and > 2^32-1 inclusive, then the above asks vn_rdwr() a negative length. > The negative length apparently gets as far as ffs_write() before > causing a panic. > > It;s a longstanding bug that ssize_t is 64 bits and SSIZE_MAX is > 2^63-1 on 64 bit machines, but writes from userland are limited to > INT_MAX (normally 2^31-1), so 64-bit applications would have a hard > time writing huge amounts. Core dumps apparently have the same > problem writing large sections. A text section with size 2GB would > be huge, but a data section with size 2GB is just large. > > The traceback should show the args, but that seems to be broken for > amd64's. Thanx for the explanation. It seems that these types of overflows will occur on more than just this location. IMHO my problem starts with the malloc-routines, and the panic is just a consequence of that. And dumping seems to suffer as an extra bonus. My tools do not allocate these huge types of data, so I probably can live with this bug. And in the testset I'll just limit the amount of space allocated. Given the level of kernel stuff I'm not into, I'll go on fixing the tools. Which are also ridled with hidden 32->64 conversions, with equal problems. --WjW