From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Patrick Steinhardt" <ps@pks.im>,
git@vger.kernel.org, "Taylor Blau" <me@ttaylorr.com>,
"Carlos Andrés Ramírez Cataño" <antaigroupltda@gmail.com>
Subject: Re: [PATCH] mailinfo: fix out-of-bounds memory reads in unquote_quoted_pair()
Date: Thu, 14 Dec 2023 16:40:57 -0500 [thread overview]
Message-ID: <20231214214057.GA2297853@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqy1dynofo.fsf@gitster.g>
On Wed, Dec 13, 2023 at 06:54:03AM -0800, Junio C Hamano wrote:
> I actually had trouble with the proposed update, and wondered if
>
> - while ((c = *in++) != 0) {
> + while ((c = *in)) {
> + in++;
>
> is easier to follow, but then was hit by the possibility that the
> same "we have incremented 'in' a bit too early" may exist if such
> a loop wants to use 'in' in its body. Wouldn't it mean that
>
> - while ((c = *in++) != 0) {
> + for (; c = *in; in++) {
>
> would be even a better rewrite?
No, the "for" loop wouldn't work, because the loop body actually depends
on "in" having already been incremented. If we find the end of the
comment or quoted string, we return "in", and the caller is expecting it
to have moved past the closing quote. So that would have to become
"return in+1".
IOW, the issue is that the normal end-of-quote parsing and hitting
end-of-string are fundamentally different. So we either need to
differentiate the returns (either with "+1" on one, or "-1" on the
other). Or we need to choose to increment "in" based on which we found
(which is what my patch does).
-Peff
prev parent reply other threads:[~2023-12-14 21:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 22:12 [PATCH] mailinfo: fix out-of-bounds memory reads in unquote_quoted_pair() Jeff King
2023-12-13 7:07 ` Patrick Steinhardt
2023-12-13 8:20 ` Jeff King
2023-12-14 7:41 ` Patrick Steinhardt
2023-12-14 21:44 ` [PATCH 0/2] avoiding recursion in mailinfo Jeff King
2023-12-14 21:47 ` [PATCH 1/2] t5100: make rfc822 comment test more careful Jeff King
2023-12-14 21:48 ` [PATCH 2/2] mailinfo: avoid recursion when unquoting From headers Jeff King
2023-12-15 7:58 ` [PATCH 0/2] avoiding recursion in mailinfo Patrick Steinhardt
2023-12-13 14:54 ` [PATCH] mailinfo: fix out-of-bounds memory reads in unquote_quoted_pair() Junio C Hamano
2023-12-14 21:40 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231214214057.GA2297853@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=antaigroupltda@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).