Re: [Xen-devel] [PATCH v2] tools: libxl: make it illegal to pass libxl__realloc(gc) a non-gc ptr

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-02-11 at 09:23 +0000, Ian Campbell wrote:
> That is, if gc is not NOGC and ptr is not NULL then ptr must be
> associated gc.
> 
> Currently in this case the new_ptr would not be registered with any
> gc, which Coverity rightly points out (in various different places)
> would be a memory leak.

This change wasn't sufficient to placate Coverity. I think it's analysis
now is a false positive, see e.g CID 1343307, but a second opinion would be
appreciated.

It doesn't seem to spot that this loop:
    for (i = 0; i < gc->alloc_maxsize; i++) {
ÂÂÂÂÂÂÂÂÂÂÂÂif (gc->alloc_ptrs[i] == ptr) {
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂgc->alloc_ptrs[i] = new_ptr;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂbreak;
ÂÂÂÂÂÂÂÂÂÂÂÂ}
ÂÂÂÂÂÂÂÂ}
either exits with i < gc->alloc_maxsize having updated alloc_ptrs or exits
with i == gc->alloc_maxsize.

Having exited the loop with "Condition i < gc->alloc_maxsize, taking false
branch" it then does "Condition i == gc->alloc_maxsize, taking false
branch", avoiding the assert (which I had hoped would be sufficient to
quash the issue). Presumably it either cannot track the possible values of
i at all or it considers the possibility that i > gc->alloc_maxsize might
be true here.

Perhaps changing the test to i >= gc->alloc_maxsize might be enough of a
hint to it? Or maybe asserting "i<=gc->alloc_maxsize" after the loop?

Or maybe this really requires modelling?

Unfortunately the actual CIDs are reported in the callers of libxl__realloc
and determining for sure that each such issue is indeed down to this mis-
analysis of the behaviour of libxl__realloc is not entirely trivial.

Ian.


> 
> It would also be possible to fix this by adding a libxl__ptr_add() at
> the same point, however semantically it seems like a programming error
> to gc-realloc a pointer which is not associated with the gc in
> question, so treat it as such.
> 
> Compile tested only, this change could expose latent bugs.
> 
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> ---
> v2: Check we actually didn't find the ptr in the gc
> ÂÂÂÂCorrect log message and shorten since LOG will inject the
> ÂÂÂÂÂÂÂfunction name.
> ---
> Âtools/libxl/libxl_internal.c | 4 ++++
> Âtools/libxl/libxl_internal.h | 4 +++-
> Â2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
> index 328046b..fc81130 100644
> --- a/tools/libxl/libxl_internal.c
> +++ b/tools/libxl/libxl_internal.c
> @@ -122,6 +122,10 @@ void *libxl__realloc(libxl__gc *gc, void *ptr,
> size_t new_size)
> ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂbreak;
> ÂÂÂÂÂÂÂÂÂÂÂÂÂ}
> ÂÂÂÂÂÂÂÂÂ}
> +ÂÂÂÂÂÂÂÂif (i == gc->alloc_maxsize) {
> +ÂÂÂÂÂÂÂÂÂÂÂÂLOG(CRITICAL, "pointer is not tracked by the given gc");
> +ÂÂÂÂÂÂÂÂÂÂÂÂabort();
> +ÂÂÂÂÂÂÂÂ}
> ÂÂÂÂÂ}
> Â
> ÂÂÂÂÂreturn new_ptr;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index fc1b558..650a958 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -617,7 +617,9 @@ _hidden void *libxl__zalloc(libxl__gc *gc_opt, size_t
> size) NN1;
> Â_hidden void *libxl__calloc(libxl__gc *gc_opt, size_t nmemb, size_t
> size) NN1;
> Â/* change the size of the memory block pointed to by @ptr to @new_size
> bytes.
> Â * unlike other allocation functions here any additional space between
> the
> - * oldsize and @new_size is not initialised (similar to a gc'd
> realloc(3)). */
> + * oldsize and @new_size is not initialised (similar to a gc'd
> realloc(3)).
> + * if @ptr is non-NULL and @gc_opt is not nogc_gc then @ptr must have
> been
> + * registered with @gc_opt previously. */
> Â_hidden void *libxl__realloc(libxl__gc *gc_opt, void *ptr, size_t
> new_size) NN1;
> Â/* print @fmt into an allocated string large enoughto contain the
> result.
> Â * (similar to gc'd asprintf(3)). */

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel