From: Derrick Stolee <derrickstolee@github.com>
To: Shaoxuan Yuan <shaoxuan.yuan02@gmail.com>,
git@vger.kernel.org, peff@peff.net
Cc: gitster@pobox.com, vdye@github.com
Subject: Re: [PATCH] builtin/mv.c: fix possible segfault in add_slash()
Date: Fri, 9 Sep 2022 10:14:00 -0400 [thread overview]
Message-ID: <3cbfd1b4-7699-1301-042c-fdadea649066@github.com> (raw)
In-Reply-To: <20220908230223.239970-1-shaoxuan.yuan02@gmail.com>
On 9/8/2022 7:02 PM, Shaoxuan Yuan wrote:
> A possible segfault was introduced in c08830de41 (mv: check if
> <destination> is a SKIP_WORKTREE_DIR, 2022-08-09).
>
> When running t7001 with SANITIZE=address, problem appears when running:
>
> git mv path1/path2/ .
> or
> git mv directory ../
> or
> any <destination> that makes dest_path[0] an empty string.
>
> The add_slash() call segfaults when dest_path[0] is an empty string,
> because it was accessing a null value in such case.
It doesn't _always_ seg fault, since we have tests that cover this
case. Adding this change will cause t7001-mv.sh to start failing
in many places:
diff --git a/builtin/mv.c b/builtin/mv.c
index 2d64c1e80fe..8216680ad3c 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -71,6 +71,10 @@ static const char **internal_prefix_pathspec(const char *prefix,
static const char *add_slash(const char *path)
{
size_t len = strlen(path);
+
+ if (!len)
+ die("segfault?");
+
if (path[len - 1] != '/') {
char *with_slash = xmalloc(st_add(len, 2));
memcpy(with_slash, path, len);
I suppose it is better to say "could segfault". Running the test
under --valgrind also causes a failure. It covers both cases, "."
and "../".
This is all to say that there is some subtlety to the situation, which
helps justify the lack of a new test case (the tests cover this case,
but require extra steps to show a failure).
> Change add_slash() to check the path argument is a non-empty string
> before accessing its value.
>
> The purpose of add_slash() is adding a slash to the end of a string to
> construct a directory path. And, because adding a slash to an empty
> string is of no use here, and checking the string value without checking
> it is non-empty leads to segfault, we should make sure the length of the
> string is positive to solve both problems.
I agree that the code change is correct.
Thanks,
-Stolee
next prev parent reply other threads:[~2022-09-09 14:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 23:02 [PATCH] builtin/mv.c: fix possible segfault in add_slash() Shaoxuan Yuan
2022-09-09 2:21 ` Jeff King
2022-09-09 14:14 ` Derrick Stolee [this message]
2022-09-09 16:37 ` Junio C Hamano
2022-09-09 19:44 ` [PATCH v2] " Shaoxuan Yuan
2022-09-09 20:04 ` Junio C Hamano
2022-09-09 22:40 ` Shaoxuan Yuan
2022-09-09 22:27 ` [PATCH v3] " Shaoxuan Yuan
2022-09-09 22:52 ` Junio C Hamano
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=3cbfd1b4-7699-1301-042c-fdadea649066@github.com \
--to=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=shaoxuan.yuan02@gmail.com \
--cc=vdye@github.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.