git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse

From
Patrick Steinhardt <ps@pks.im>
Date
Jun 10, 2024, 05:55 UTC
Message-ID
<ZmaVYnmgyAr0vapK@tanuki>
In-Reply-To
<4aceb9233ed24fb1e1a324a77b665eea2cf22b39.1717946847.git.me@ttaylorr.com>
On Sun, Jun 09, 2024 at 11:27:35AM -0400, Taylor Blau wrote:
Show 5 quoted lines
> In 795006fff4 (pack-bitmap: gracefully handle missing BTMP chunks,
> 2024-04-15), we refactored the reuse_partial_packfile_from_bitmap()
> function and stopped assigning the pack_int_id field when reusing only
> the MIDX's preferred pack. This results in an uninitialized read down in
> try_partial_reuse() like so:

I feel like I'm blind, but I cannot see how the patch changed what we do with `pack_int_id`. It's not mentioned a single time in the diff, so how did it have the effect of not setting it anymore?

Show 33 quoted lines
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index fe8e8a51d3..8b9a2c698f 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -2073,6 +2073,7 @@ void reuse_partial_packfile_from_bitmap(struct bitmap_index *bitmap_git,
>  		QSORT(packs, packs_nr, bitmapped_pack_cmp);
>  	} else {
>  		struct packed_git *pack;
> +		uint32_t pack_int_id;
> 
>  		if (bitmap_is_midx(bitmap_git)) {
>  			uint32_t preferred_pack_pos;
> @@ -2083,12 +2084,21 @@ void reuse_partial_packfile_from_bitmap(struct bitmap_index *bitmap_git,
>  			}
> 
>  			pack = bitmap_git->midx->packs[preferred_pack_pos];
> +			pack_int_id = preferred_pack_pos;
>  		} else {
>  			pack = bitmap_git->pack;
> +			/*
> +			 * Any value for 'pack_int_id' will do here. When we
> +			 * process the pack via try_partial_reuse(), we won't
> +			 * use the `pack_int_id` field since we have a non-MIDX
> +			 * bitmap.
> +			 */
> +			pack_int_id = 0;
>  		}
> 
>  		ALLOC_GROW(packs, packs_nr + 1, packs_alloc);
>  		packs[packs_nr].p = pack;
> +		packs[packs_nr].pack_int_id = pack_int_id;
>  		packs[packs_nr].bitmap_nr = pack->num_objects;
>  		packs[packs_nr].bitmap_pos = 0;

Okay, the patch looks trivial enough. I was wondering whether we might want to `memset(&packs[packs_nr], 0, sizeof(packs[packs_nr]))` as it feels rather easy to miss initialization of one of the members. But on the other hand, this might also cause us to paper over bugs if we did that.

Patrick
Previous: Taylor BlauNext: Taylor Blau
Message 2 of 15 in “pack-bitmap.c: avoid uninitialized `pack_int_id` during reuse”
  1. pack-bitmap.c: avoid uninitialized `pack_int_id` during reuseTaylor Blau, Jun 9, 2024
  2. Patrick SteinhardtJun 10, 2024
  3. Taylor BlauJun 10, 2024
  4. Patrick SteinhardtJun 11, 2024
  5. 0/3 midx: various brown paper bag fixesTaylor Blau, Jun 10, 2024
  6. 1/3 midx-write.c: do not read existing MIDX with `packs_to_include`Taylor Blau, Jun 10, 2024
  7. 2/3 pack-bitmap.c: avoid uninitialized `pack_int_id` during reuseTaylor Blau, Jun 10, 2024
  8. Jeff KingJun 11, 2024
  9. Junio C HamanoJun 11, 2024
  10. 3/3 pack-revindex.c: guard against out-of-bounds pack lookupsTaylor Blau, Jun 10, 2024
  11. 0/3 midx: various brown paper bag fixesTaylor Blau, Jun 11, 2024
  12. 1/3 midx-write.c: do not read existing MIDX with `packs_to_include`Taylor Blau, Jun 11, 2024
  13. 2/3 pack-bitmap.c: avoid uninitialized `pack_int_id` during reuseTaylor Blau, Jun 11, 2024
  14. 3/3 pack-revindex.c: guard against out-of-bounds pack lookupsTaylor Blau, Jun 11, 2024
  15. Taylor BlauJun 11, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.