From owner-svn-src-all@FreeBSD.ORG Mon May 5 22:52:36 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74952AD2 for ; Mon, 5 May 2014 22:52:36 +0000 (UTC) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBB02E85 for ; Mon, 5 May 2014 22:52:35 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id 10so622397lbg.18 for ; Mon, 05 May 2014 15:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EuuAx8swSzUxIg4hr5PecUXRQ9bhiVlvTWAvvu+sSS8=; b=FYaRAgTVpq0HlTsIuLW5MGuK7hC7hbVSxmntYJZmZ706FiSuX7oHfa7nbxKSL1IZvr 1AF66l1NBCuP+rnH+u0K1WQHhKbDhvhx3Bkyu+KD238fMIp0u8HOIhhxAyIu5XD6Ha5Z OFRgJzAMegWq5Uu7fT0f9YjFeqMn1pbiZ3DOQcCdZSc+RnLKKSIT0yeuZjrMGqMGT69w f3e/ew4NFvPCftd2RrBfUfCV8rjJIkeLFF3nuyFFc9Kuo6qjs+PsUW6pO1nvZL4tDoiG rNExMkMiTHekdpvtkcOb0cbJ69GmzzfgIqKKwMQADGCDPaq+Pws0oLprBguilDE6nsBc nZbQ== X-Gm-Message-State: ALoCoQnXbPhvqN+mdDxk0/jMpAPtOY7t1hlpIhEYpnqKJoWruRPiljLUcqm6xqAkxT3FUr4ObZ2T X-Received: by 10.152.87.71 with SMTP id v7mr14308124laz.10.1399330348155; Mon, 05 May 2014 15:52:28 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id ms3sm11046078lbb.17.2014.05.05.15.52.27 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 May 2014 15:52:27 -0700 (PDT) Message-ID: <5368162A.9000002@freebsd.org> Date: Tue, 06 May 2014 02:52:26 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Chisnall Subject: Re: svn commit: r265367 - head/lib/libc/regex References: <201405051641.s45GfFje086423@svn.freebsd.org> <5367CD77.40909@freebsd.org> <5367EB54.1080109@FreeBSD.org> <3C7CFFB7-5C84-4AC1-9A81-C718D184E87B@FreeBSD.org> <7D7A417E-17C3-4001-8E79-0B57636A70E1@gmail.com> <536807D8.9000005@freebsd.org> <9349EAA9-F92C-4170-A1C0-2200FD490E5F@FreeBSD.org> In-Reply-To: <9349EAA9-F92C-4170-A1C0-2200FD490E5F@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, Pedro Giffuni , src-committers , Warner Losh X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 22:52:36 -0000 On 06.05.2014 2:12, David Chisnall wrote: > On 5 May 2014, at 22:51, Andrey Chernov wrote: > >> For standard malloc/realloc interface it is up to the caller to check >> n*size not overflows. You must trust caller already does such check. > > Do a search of the CVE database sometime to see how well placed that trust generally is. Or even look at the code in question, where none of the realloc() or malloc() calls does overflow checking. I know current situation and disagree with OpenBSD way to fix it. Public interface assumes that caller should be trusted. Period. How well it is really trusted is up to the caller and should be fixed in it clearly, allowing human to trace the logic. >> Using calloc() to enforce it instead of caller is semantically wrong, > > Relying on a standard function to behave according to the standard is semantically wrong? Yes. Generally it is using a function outside of its purpose. I.e. you can use calloc() just to check n*size and nothing else (free() result immediately afterwards) instead of writing just single check by yourself. It will be legal usage but semantically wrong and misleading. >> and especially strange when the caller is standard C library under your >> control. > > I don't follow this. If libc can't rely on standards conformance from itself then other code stands no chance. Libc here is the caller which is well under control because of the same codebase. It means that n*size check can be easily added before malloc call instead of using side effects with hidden logic. As I mention initially, literal enough checks is what we need to make logic clear. In the case we discuss realloc() can be changed by reallocf() which does n*size and NULL checks and literal "if" should be added before malloc() to check overflow. -- http://ache.vniz.net/