Re: [PATCH v2 00/11] Reftable coverity fixes

On Wed, Dec 08, 2021 at 09:49:35PM +0000, Han-Wen Nienhuys via GitGitGadget wrote:

  2:  603bd1d4f6e !  2:  1ddcfe61ebc reftable: fix resource leak in error path
     @@ reftable/block.c: int block_reader_init(struct block_reader *br, struct reftable
       
       	if (typ == BLOCK_TYPE_LOG) {
       		int block_header_skip = 4 + header_off;
     +@@ reftable/block.c: int block_reader_init(struct block_reader *br, struct reftable_block *block,
     + 		uLongf src_len = block->len - block_header_skip;
     + 		/* Log blocks specify the *uncompressed* size in their header.
     + 		 */
     +-		uint8_t *uncompressed = reftable_malloc(sz);
     ++		uncompressed = reftable_malloc(sz);
     + 
     + 		/* Copy over the block header verbatim. It's not compressed. */
     + 		memcpy(uncompressed, block->data, block_header_skip);

This drops the shadowed variable, but it needs a little more. In one of
the error blocks we still free the variable, and then jump to the
"done" label, which will try to free it again. So you need:

diff --git a/reftable/block.c b/reftable/block.c
index 0bc4a5d84b..6d55817e0d 100644
--- a/reftable/block.c
+++ b/reftable/block.c

@@ -215,7 +215,6 @@ int block_reader_init(struct block_reader *br, struct reftable_block *block,
 		if (Z_OK !=
 		    uncompress2(uncompressed + block_header_skip, &dst_len,
 				block->data + block_header_skip, &src_len)) {
-			reftable_free(uncompressed);
 			err = REFTABLE_ZLIB_ERROR;
 			goto done;
 		}

to avoid the double-free. I think it's otherwise OK. The other error
case does not try to free, and in the success case we hand off ownership
of "uncompressed" and set it back to NULL.

I doubt this is the cause of the segfault on Windows, though (I saw it
via Coverity). That one still puzzles me, and I suspect will need more
output to figure out. It's possible to get an interactive session on the
Windows VM running the CI:

  https://github.com/marketplace/actions/debugging-with-tmate

but I haven't tried it myself. I'm also not sure what tools are
available there (gdb sure would be nice, but even a backtrace of the
segfault would be quite a lot; I wonder if we could build with ASan on
Windows).

-Peff