svn commit: r300547 - in head: lib/libcam sbin/camcontrol sbin/iscontrol sys/cam usr.sbin/camdd usr.sbin/mptutil

[Don Lewis]

On 24 May, To: src-committers at 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 ...