Date: Mon, 23 May 2016 19:27:18 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r300547 - in head: lib/libcam sbin/camcontrol sbin/iscontrol sys/cam usr.sbin/camdd usr.sbin/mptutil Message-ID: <201605240227.u4O2RIOc099919@gw.catspoiler.org> In-Reply-To: <201605240057.u4O0vBfL057675@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201605240227.u4O2RIOc099919>