From owner-freebsd-current@FreeBSD.ORG Mon May 31 13:26:42 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 50FD516A4CE for ; Mon, 31 May 2004 13:26:42 -0700 (PDT) Received: from freebee.digiware.nl (dsl390.iae.nl [212.61.63.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id F328443D46 for ; Mon, 31 May 2004 13:26:40 -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 i4VKLC67076664; Mon, 31 May 2004 22:21:12 +0200 (CEST) (envelope-from wjw@withagen.nl) Message-ID: <0bdb01c4474c$e247a810$471b3dd4@dual> From: "Willem Jan Withagen" To: "Willem Jan Withagen" , "Bruce Evans" Date: Mon, 31 May 2004 22:21:29 +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: Mon, 31 May 2004 20:26:42 -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. Am I right in assuming that instead of 'int len' as parameter it then should read ssize_t??? Since that is what the description of ssize_t is. Although I would expect ssize_t to be defined unsigned.. --WjW