From: Eric Sunshine <sunshine@sunshineco.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Florian Schmidt <flosch@nutanix.com>,
git@vger.kernel.org,
Jonathan Davies <jonathan.davies@nutanix.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>,
Denton Liu <liu.denton@gmail.com>,
Linus Arver <linusa@google.com>
Subject: Re: [PATCH] wt-status: Don't find scissors line beyond buf len
Date: Thu, 7 Mar 2024 16:09:15 -0500 [thread overview]
Message-ID: <CAPig+cTgusL7OH=5DJY9ef4YuLw5WBKgDFcbSu=QKFjjkforkw@mail.gmail.com> (raw)
In-Reply-To: <xmqq7cidlqg5.fsf@gitster.g>
On Thu, Mar 7, 2024 at 3:47 PM Junio C Hamano <gitster@pobox.com> wrote:
> * So here is the version I queued. I have a new paragraph at the
> end of the log message to talk about use of strstr() and how it
> is OK in the current codebase.
> [jc: tweaked the commit log message and the implementation a bit]
>
> From: Florian Schmidt <flosch@nutanix.com>
>
> In general, if wt_status_locate_end() is given a piece of the memory
> that lacks NUL at all, strstr() may continue across page boundaries
> and run into an unmapped page. For our current callers, this is not
> a problem, as all of them except one uses a memory owned by a strbuf
> (which guarantees an implicit NUL-termination after its payload),
> and the one exeption in trailer.c:find_end_of_log_message() uses
> strlen() to compute the length before calling this function.
s/exeption/exception/
next prev parent reply other threads:[~2024-03-07 21:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 18:37 [PATCH] wt-status: Don't find scissors line beyond buf len Florian Schmidt
2024-03-07 19:20 ` Junio C Hamano
2024-03-07 20:47 ` Junio C Hamano
2024-03-07 21:09 ` Eric Sunshine [this message]
2024-03-07 21:15 ` Kristoffer Haugsbakk
2024-03-07 21:24 ` Junio C Hamano
2024-03-07 21:26 ` Eric Sunshine
2024-03-07 21:30 ` Kristoffer Haugsbakk
2024-03-08 9:08 ` Florian Schmidt
2024-03-08 15:26 ` Junio C Hamano
2024-03-08 17:43 ` Florian Schmidt
2024-04-06 1:37 ` Linus Arver
2024-03-07 19:35 ` Junio C Hamano
2024-03-08 9:13 ` Florian Schmidt
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='CAPig+cTgusL7OH=5DJY9ef4YuLw5WBKgDFcbSu=QKFjjkforkw@mail.gmail.com' \
--to=sunshine@sunshineco.com \
--cc=flosch@nutanix.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonathan.davies@nutanix.com \
--cc=linusa@google.com \
--cc=liu.denton@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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).