{"thread":{"id":"64713","subject":"[PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","startedAt":"2026-01-02T19:17:01Z","lastAt":"2026-01-04T10:33:32Z","messageCount":6,"participants":["Tsahi Elkayam","Pushkar Singh","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"532936","messageId":"Q0zfHYp-_TO2h_5PXPG9KjHwpMKIf2o2u2dsaoAjIsScmA3W6t7IvqIEeLfM7auEFIQyazlNnA3MGAuS4AANF0yfEBJAjkU1bWp-NH9m89U=@protonmail.com","threadId":"64713","inReplyTo":null,"subject":"[PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","fromName":"Tsahi Elkayam","fromEmail":"tsahi.elkayam@protonmail.com","sentAt":"2026-01-02T19:16:49Z","receivedAt":"2026-01-02T19:17:01Z","isPatch":true,"sender":{"key":"tsahi.elkayam@protonmail.com","avatar":null},"body":"\n\n The indexed_table_ref_iter_next() function accesses ref->value.val2\n without first checking the ref's value_type. This is undefined behavior\n when the ref is not of type REFTABLE_REF_VAL2.\n\n The correct pattern is already used in filtering_ref_iterator_next()\n which checks value_type before accessing the appropriate union member.\n Apply the same pattern here:\n\n - Check for REFTABLE_REF_VAL2 before accessing val2 members\n - Add missing check for REFTABLE_REF_VAL1 to handle single-value refs\n\n This was marked with a \"/* BUG */\" comment indicating the issue was\n known but not yet fixed.\n\n Signed-off-by: Tsahi Elkayam \n ---\n reftable/iter.c | 13 ++++++++-----\n 1 file changed, 8 insertions(+), 5 deletions(-)\n\n diff --git a/reftable/iter.c b/reftable/iter.c\n index 2ecc52b336..2eee65bb1e 100644\n --- a/reftable/iter.c\n +++ b/reftable/iter.c\n @@ -171,12 +171,15 @@ static int indexed_table_ref_iter_next(void *p, struct reftable_record *rec)\n \t\t\t}\n \t\t\tcontinue;\n \t\t}\n -\t\t/* BUG */\n -\t\tif (!memcmp(it->oid.buf, ref->value.val2.target_value,\n -\t\t\t it->oid.len) ||\n -\t\t !memcmp(it->oid.buf, ref->value.val2.value, it->oid.len)) {\n +\t\tif (ref->value_type == REFTABLE_REF_VAL2 &&\n +\t\t (!memcmp(it->oid.buf, ref->value.val2.target_value,\n +\t\t\t it->oid.len) ||\n +\t\t !memcmp(it->oid.buf, ref->value.val2.value, it->oid.len)))\n +\t\t\treturn 0;\n +\n +\t\tif (ref->value_type == REFTABLE_REF_VAL1 &&\n +\t\t !memcmp(it->oid.buf, ref->value.val1, it->oid.len))\n \t\t\treturn 0;\n -\t\t}\n \t}\n }\n\n -- \n 2.37.1 (Apple Git-137.1)\n"},{"id":"532944","messageId":"CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com","threadId":"64713","inReplyTo":"Q0zfHYp-_TO2h_5PXPG9KjHwpMKIf2o2u2dsaoAjIsScmA3W6t7IvqIEeLfM7auEFIQyazlNnA3MGAuS4AANF0yfEBJAjkU1bWp-NH9m89U=@protonmail.com","subject":"Re: [PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","fromName":"Pushkar Singh","fromEmail":"pushkarkumarsingh1970@gmail.com","sentAt":"2026-01-03T07:35:29Z","receivedAt":"2026-01-03T07:35:41Z","isPatch":true,"sender":{"key":"pushkarkumarsingh1970@gmail.com","avatar":"https://avatars.githubusercontent.com/u/173247767?v=4"},"body":"Hi Tsahi,\n\nThanks for working on this.\n\nThe issue and fix make sense to me. Guarding access to the val2 members\nbehind a value_type check avoids the undefined behavior noted by the\nexisting comment, and explicitly handling REFTABLE_REF_VAL1 here matches\nthe pattern already used in filtering_ref_iterator_next().\n\nI didn’t spot any issues with the control flow or logic in this change.\n\nThanks for addressing this.\n\nPushkar\n\nOn Sat, Jan 3, 2026 at 12:47 AM Tsahi Elkayam\n wrote:\n>\n>\n>\n> The indexed_table_ref_iter_next() function accesses ref->value.val2\n> without first checking the ref's value_type. This is undefined behavior\n> when the ref is not of type REFTABLE_REF_VAL2.\n>\n> The correct pattern is already used in filtering_ref_iterator_next()\n> which checks value_type before accessing the appropriate union member.\n> Apply the same pattern here:\n>\n> - Check for REFTABLE_REF_VAL2 before accessing val2 members\n> - Add missing check for REFTABLE_REF_VAL1 to handle single-value refs\n>\n> This was marked with a \"/* BUG */\" comment indicating the issue was\n> known but not yet fixed.\n>\n> Signed-off-by: Tsahi Elkayam \n> ---\n> reftable/iter.c | 13 ++++++++-----\n> 1 file changed, 8 insertions(+), 5 deletions(-)\n>\n> diff --git a/reftable/iter.c b/reftable/iter.c\n> index 2ecc52b336..2eee65bb1e 100644\n> --- a/reftable/iter.c\n> +++ b/reftable/iter.c\n> @@ -171,12 +171,15 @@ static int indexed_table_ref_iter_next(void *p, struct reftable_record *rec)\n> }\n> continue;\n> }\n> - /* BUG */\n> - if (!memcmp(it->oid.buf, ref->value.val2.target_value,\n> - it->oid.len) ||\n> - !memcmp(it->oid.buf, ref->value.val2.value, it->oid.len)) {\n> + if (ref->value_type == REFTABLE_REF_VAL2 &&\n> + (!memcmp(it->oid.buf, ref->value.val2.target_value,\n> + it->oid.len) ||\n> + !memcmp(it->oid.buf, ref->value.val2.value, it->oid.len)))\n> + return 0;\n> +\n> + if (ref->value_type == REFTABLE_REF_VAL1 &&\n> + !memcmp(it->oid.buf, ref->value.val1, it->oid.len))\n> return 0;\n> - }\n> }\n> }\n>\n> --\n> 2.37.1 (Apple Git-137.1)\n>\n"},{"id":"532968","messageId":"xmqqy0menlc3.fsf@gitster.g","threadId":"64713","inReplyTo":"Q0zfHYp-_TO2h_5PXPG9KjHwpMKIf2o2u2dsaoAjIsScmA3W6t7IvqIEeLfM7auEFIQyazlNnA3MGAuS4AANF0yfEBJAjkU1bWp-NH9m89U=@protonmail.com","subject":"Re: [PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-01-04T02:49:32Z","receivedAt":"2026-01-04T02:49:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tsahi Elkayam writes:\n\n> The indexed_table_ref_iter_next() function accesses ref->value.val2\n> without first checking the ref's value_type. This is undefined behavior\n> when the ref is not of type REFTABLE_REF_VAL2.\n>\n> The correct pattern is already used in filtering_ref_iterator_next()\n> which checks value_type before accessing the appropriate union member.\n> Apply the same pattern here:\n>\n> - Check for REFTABLE_REF_VAL2 before accessing val2 members\n> - Add missing check for REFTABLE_REF_VAL1 to handle single-value refs\n>\n> This was marked with a \"/* BUG */\" comment indicating the issue was\n> known but not yet fixed.\n>\n> Signed-off-by: Tsahi Elkayam \n> ---\n> reftable/iter.c | 13 ++++++++-----\n> 1 file changed, 8 insertions(+), 5 deletions(-)\n>\n> diff --git a/reftable/iter.c b/reftable/iter.c\n> index 2ecc52b336..2eee65bb1e 100644\n> --- a/reftable/iter.c\n> +++ b/reftable/iter.c\n\nWhat are these lines with two-whitespace indent about? When sending\na patch purely for discussion (because the actual change may be iffy\nor dangerous), we sometimes deliberately corrupt the patch not to\napply mechanically, but this patch does not seem to be such a\n\"request for discussion\" patch.\n\n"},{"id":"532979","messageId":"vKH4wrIZEyr9jZkXQad8wEowMcZq4fewU0z92Fdvv06lwH3e-pDFrvqjvehUFnmxO48-VGbwBP-ZzFubTlQEoIMeruyhqGBdRLmyU61nZ-k=@protonmail.com","threadId":"64713","inReplyTo":"CALE2CrQTvHeu21yLXtRg=A6ak9AB_vvwPirQNFDjZ2AmhoTzTQ@mail.gmail.com","subject":"Re: [PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","fromName":"Tsahi Elkayam","fromEmail":"tsahi.elkayam@protonmail.com","sentAt":"2026-01-04T10:13:09Z","receivedAt":"2026-01-04T10:13:22Z","isPatch":true,"sender":{"key":"tsahi.elkayam@protonmail.com","avatar":null},"body":"This is my first contribution attempt I am so happy I didn’t messed it up\nI found few more issues I will address them one by one\nYou made my day thank you\n\n\nSent from Proton Mail for iOS.\n\n-------- Original Message --------\nOn Saturday, 01/03/26 at 09:35 Pushkar Singh wrote:\nHi Tsahi,\n\nThanks for working on this.\n\nThe issue and fix make sense to me. Guarding access to the val2 members\nbehind a value_type check avoids the undefined behavior noted by the\nexisting comment, and explicitly handling REFTABLE_REF_VAL1 here matches\nthe pattern already used in filtering_ref_iterator_next().\n\nI didn’t spot any issues with the control flow or logic in this change.\n\nThanks for addressing this.\n\nPushkar\n\nOn Sat, Jan 3, 2026 at 12:47 AM Tsahi Elkayam\n wrote:\n>\n>\n>\n> The indexed_table_ref_iter_next() function accesses ref->value.val2\n> without first checking the ref's value_type. This is undefined behavior\n> when the ref is not of type REFTABLE_REF_VAL2.\n>\n> The correct pattern is already used in filtering_ref_iterator_next()\n> which checks value_type before accessing the appropriate union member.\n> Apply the same pattern here:\n>\n> - Check for REFTABLE_REF_VAL2 before accessing val2 members\n> - Add missing check for REFTABLE_REF_VAL1 to handle single-value refs\n>\n> This was marked with a \"/* BUG */\" comment indicating the issue was\n> known but not yet fixed.\n>\n> Signed-off-by: Tsahi Elkayam \n> ---\n> reftable/iter.c | 13 ++++++++-----\n> 1 file changed, 8 insertions(+), 5 deletions(-)\n>\n> diff --git a/reftable/iter.c b/reftable/iter.c\n> index 2ecc52b336..2eee65bb1e 100644\n> --- a/reftable/iter.c\n> +++ b/reftable/iter.c\n> @@ -171,12 +171,15 @@ static int indexed_table_ref_iter_next(void *p, struct reftable_record *rec)\n> }\n> continue;\n> }\n> - /* BUG */\n> - if (!memcmp(it->oid.buf, ref->value.val2.target_value,\n> - it->oid.len) ||\n> - !memcmp(it->oid.buf, ref->value.val2.value, it->oid.len)) {\n> + if (ref->value_type == REFTABLE_REF_VAL2 &&\n> + (!memcmp(it->oid.buf, ref->value.val2.target_value,\n> + it->oid.len) ||\n> + !memcmp(it->oid.buf, ref->value.val2.value, it->oid.len)))\n> + return 0;\n> +\n> + if (ref->value_type == REFTABLE_REF_VAL1 &&\n> + !memcmp(it->oid.buf, ref->value.val1, it->oid.len))\n> return 0;\n> - }\n> }\n> }\n>\n> --\n> 2.37.1 (Apple Git-137.1)\n>\n\n"},{"id":"532980","messageId":"W6v12kkhI_qyFV03jZJriHkrs5pYt8tHCD4ve0bWxikUYAGasvwwWDV3Df67dM2ttRh49EECD_Ph84NbtpxE1Opv-Z03UcE7vtbMjsYhfWs=@protonmail.com","threadId":"64713","inReplyTo":"xmqqy0menlc3.fsf@gitster.g","subject":"Re: [PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","fromName":"Tsahi Elkayam","fromEmail":"tsahi.elkayam@protonmail.com","sentAt":"2026-01-04T10:22:14Z","receivedAt":"2026-01-04T10:22:24Z","isPatch":true,"sender":{"key":"tsahi.elkayam@protonmail.com","avatar":null},"body":"So I did messed up\nsorry lesson learned\nbut still...\nwow very exciting \n\n\nSent from Proton Mail for iOS.\n\n-------- Original Message --------\nOn Sunday, 01/04/26 at 04:49 Junio C Hamano wrote:\nTsahi Elkayam writes:\n\n> The indexed_table_ref_iter_next() function accesses ref->value.val2\n> without first checking the ref's value_type. This is undefined behavior\n> when the ref is not of type REFTABLE_REF_VAL2.\n>\n> The correct pattern is already used in filtering_ref_iterator_next()\n> which checks value_type before accessing the appropriate union member.\n> Apply the same pattern here:\n>\n> - Check for REFTABLE_REF_VAL2 before accessing val2 members\n> - Add missing check for REFTABLE_REF_VAL1 to handle single-value refs\n>\n> This was marked with a \"/* BUG */\" comment indicating the issue was\n> known but not yet fixed.\n>\n> Signed-off-by: Tsahi Elkayam \n> ---\n> reftable/iter.c | 13 ++++++++-----\n> 1 file changed, 8 insertions(+), 5 deletions(-)\n>\n> diff --git a/reftable/iter.c b/reftable/iter.c\n> index 2ecc52b336..2eee65bb1e 100644\n> --- a/reftable/iter.c\n> +++ b/reftable/iter.c\n\nWhat are these lines with two-whitespace indent about? When sending\na patch purely for discussion (because the actual change may be iffy\nor dangerous), we sometimes deliberately corrupt the patch not to\napply mechanically, but this patch does not seem to be such a\n\"request for discussion\" patch.\n\n\n"},{"id":"532982","messageId":"aHbWlZCRqQoHJ3jf12sxAyC7dEuzxCJ82PCtxH1RLcE23XSa7n8jl3yyoJ382TZ45H4pTuewB4WR72yL_zVzadotQ8UIVOBXpIkld45Ieew=@protonmail.com","threadId":"64713","inReplyTo":"W6v12kkhI_qyFV03jZJriHkrs5pYt8tHCD4ve0bWxikUYAGasvwwWDV3Df67dM2ttRh49EECD_Ph84NbtpxE1Opv-Z03UcE7vtbMjsYhfWs=@protonmail.com","subject":"Re: [PATCH] reftable/iter: fix undefined behavior in indexed_table_ref_iter_next","fromName":"Tsahi Elkayam","fromEmail":"tsahi.elkayam@protonmail.com","sentAt":"2026-01-04T10:33:12Z","receivedAt":"2026-01-04T10:33:32Z","isPatch":true,"sender":{"key":"tsahi.elkayam@protonmail.com","avatar":null},"body":"Hi Junio,\n\nThank you very much for your feedback. It is a great honor for me to receive a response from you.\n\nI apologize for the formatting issues in my previous email. I am a new developer and still learning the community's workflow. English is not my native language, and I mistakenly added indentation when composing the email, which I now realize corrupted the patch.\n\nI will send a corrected Version 2 (v2) of the patch shortly, ensuring that the format is preserved correctly.\n\nThank you for your patience and for the \"lesson learned.\"\n\nBest regards, Tsahi\n\n\n\n\nSent with Proton Mail secure email.\n\nOn Sunday, January 4th, 2026 at 12:22 PM, Tsahi Elkayam wrote:\n\n> \n> \n> So I did messed up\n> sorry lesson learned\n> but still...\n> wow very exciting\n> \n> \n> Sent from Proton Mail for iOS.\n> \n> -------- Original Message --------\n> On Sunday, 01/04/26 at 04:49 Junio C Hamano gitster@pobox.com wrote:\n> \n> Tsahi Elkayam Tsahi.Elkayam@protonmail.com writes:\n> \n> > The indexed_table_ref_iter_next() function accesses ref->value.val2\n> > without first checking the ref's value_type. This is undefined behavior\n> > when the ref is not of type REFTABLE_REF_VAL2.\n> > \n> > The correct pattern is already used in filtering_ref_iterator_next()\n> > which checks value_type before accessing the appropriate union member.\n> > Apply the same pattern here:\n> > \n> > - Check for REFTABLE_REF_VAL2 before accessing val2 members\n> > - Add missing check for REFTABLE_REF_VAL1 to handle single-value refs\n> > \n> > This was marked with a \"/* BUG */\" comment indicating the issue was\n> > known but not yet fixed.\n> > \n> > Signed-off-by: Tsahi Elkayam Tsahi.Elkayam@protonmail.com\n> > ---\n> > reftable/iter.c | 13 ++++++++-----\n> > 1 file changed, 8 insertions(+), 5 deletions(-)\n> > \n> > diff --git a/reftable/iter.c b/reftable/iter.c\n> > index 2ecc52b336..2eee65bb1e 100644\n> > --- a/reftable/iter.c\n> > +++ b/reftable/iter.c\n> \n> \n> What are these lines with two-whitespace indent about? When sending\n> a patch purely for discussion (because the actual change may be iffy\n> or dangerous), we sometimes deliberately corrupt the patch not to\n> apply mechanically, but this patch does not seem to be such a\n> \"request for discussion\" patch.\n"}]}