From owner-svn-src-head@FreeBSD.ORG Mon May 5 22:52:36 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87AC1AD3 for ; Mon, 5 May 2014 22:52:36 +0000 (UTC) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 04C8DE86 for ; Mon, 5 May 2014 22:52:35 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so1488469lbv.35 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=GBORT4Yu62KG6ew9ed0YotBT7REIHfuagHPrsb/XqTslM0oaZv7yCA7PcpCkZzgKdr jeR0L0fN9YHygpRMzRB4rvgI46tUgMt11Wlqk+cbnVhfHO0mud3Q3Bi/aXOsRLQRcHsD DYvpdj5eCjbPz8a2GrOMB7pCt/VESUlVvrUbQ5hTZtGn7kZef3O+AjPyyO7Qczkf06Wh NHxg2kvOGTEFkqWya/akF6QdnVO/DWxxo+1zbJ5K/DZei/OSIlIhfwLr2ZiOHVEDO2YJ c6ovD66PrOSF/elqp8W8WaJ+B7gHXrGQCgNTuTpVnoHW6JYqh43SKq0bC2d/xwJTetps PtXA== X-Gm-Message-State: ALoCoQnDhfh4kXszEHLCF82WH9QWN9wtUG4m5vfZjJCpEoVgEkzxff0CJWq4utSD6ue/yJcCrfuJ 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-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current 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/