From owner-svn-src-all@freebsd.org Tue May 24 02:27:27 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EDE32B47A93; Tue, 24 May 2016 02:27:27 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AFCA71767; Tue, 24 May 2016 02:27:27 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id u4O2RIOc099919; Mon, 23 May 2016 19:27:23 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201605240227.u4O2RIOc099919@gw.catspoiler.org> Date: Mon, 23 May 2016 19:27:18 -0700 (PDT) From: Don Lewis Subject: Re: svn commit: r300547 - in head: lib/libcam sbin/camcontrol sbin/iscontrol sys/cam usr.sbin/camdd usr.sbin/mptutil To: src-committers@freebsd.org cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org In-Reply-To: <201605240057.u4O0vBfL057675@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.22 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: Tue, 24 May 2016 02:27:28 -0000 On 24 May, To: src-committers@freebsd.org wrote: > Author: truckman > Date: Tue May 24 00:57:11 2016 > New Revision: 300547 > URL: https://svnweb.freebsd.org/changeset/base/300547 > > Log: > Fix multiple Coverity Out-of-bounds access false postive issues in CAM > > The currently used idiom for clearing the part of a ccb after its > header generates one or two Coverity errors for each time it is > used. All instances generate an Out-of-bounds access (ARRAY_VS_SINGLETON) > error because of the treatment of the header as a two element array, > with a pointer to the non-existent second element being passed as > the starting address to bzero(). Some instances also alsp generate > Out-of-bounds access (OVERRUN) errors, probably because the space > being cleared is larger than the sizeofstruct ccb_hdr). > > In addition, this idiom is difficult for humans to understand and > it is error prone. The user has to chose the proper struct ccb_* > type (which does not appear in the surrounding code) for the sizeof() > in the length calculation. I found several instances where the > length was incorrect, which could cause either an actual out of > bounds write, or incompletely clear the ccb. > > A better way is to write the code to clear the ccb itself starting > at sizeof(ccb_hdr) bytes from the start of the ccb, and calculate > the length based on the specific type of struct ccb_* being cleared > as specified by the union ccb member being used. The latter can > normally be seen in the nearby code. This is friendlier for Coverity > and other static analysis tools because they will see that the > intent is to clear the trailing part of the ccb. > > Wrap all of the boilerplate code in a convenient macro that only > requires a pointer to the desired union ccb member (or a pointer > to the union ccb itself) as an argument. [snip] > Reviewed by: scottl, ken, delphij, imp > MFH: 1 month > Differential Revision: https://reviews.freebsd.org/D6496 grr ... that should be: MFC after: 1 month This mistake is too easy to make ...