Skip to content

worktree: Fix out of bounds read that causes data loss and reject invalid empty input in worktree add#2187

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rimrul wants to merge 2 commits into
base:master
Choose a base branch
from
Open

worktree: Fix out of bounds read that causes data loss and reject invalid empty input in worktree add #2187

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8bc69c6
worktree: don't read out of bounds
rimrul Jul 25, 2026
ec682d7
worktree: reject empty string
rimrul Jul 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 13 additions & 7 deletions builtin/worktree.c
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -297,17 +297,21 @@ static void remove_junk_on_signal(int signo)
static const char *worktree_basename(const char *path, int *olen)

@gitgitgadgetgitgitgadgetBotJul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Junio C Hamano wrote on the Git mailing list (how to reply to this email):

"Matthias Aßhauer via GitGitGadget" <gitgitgadget@gmail.com> writes:
> `worktree_basename` tries to read from memory before the passed `path`> string, if `path` is empty (or only consists of directory separators).> That results in unexpected nonsense data being returned to the caller,> which can lead to issues, such as `git worktree add ""` recursively> deleting the current working directory, including `.git`.
OK, so you do want to handle a case where path is something silly
like "///".
> Stop reading out of bounds in these cases to avoid that behaviour.>> This leads to `git worktree add ""` consistently exiting with the> message `BUG: How come '' becomes empty after sanitization?`, which is> still undesirable, but at least it doesn't result in data loss anymore.
OK.
> diff --git a/builtin/worktree.c b/builtin/worktree.c> index 4bc7b4f6e7..d8188035db 100644> --- a/builtin/worktree.c> +++ b/builtin/worktree.c> @@ -297,17 +297,21 @@ static void remove_junk_on_signal(int signo)> static const char *worktree_basename(const char *path, int *olen)> {> const char *name;> -	int len;> +	int len, len2;>> -	len = strlen(path);> +	len2 = len = strlen(path);> while (len && is_dir_sep(path[len - 1]))> len--;
These two 'len' variables should have clear names to distinguish
what each length represents. Rather than introducing a cryptic
'len2', give it a more meaningful name, and rename 'len' as well if
necessary.
I suspect that it is to remember the original length of the 'path'
before stripping the trailing directory separators?
> -	for (name = path + len - 1; name > path; name--)> - if (is_dir_sep(*name)) {> - name++;> - break;> - }
When 'len' is 0, the original code sets 'name' to '&path[-1]' and
does not enter the loop. However, '*olen' is set to 0, and 'name',
pointing before the start of the string, is returned. If left
unfixed, callers pass it to xstrndup(), strbuf_add(), and the like,
reading memory before the start of the string, which is horrible and
worth fixing.
> +	if(len) {> + for (name = path + len - 1; name > path; name--)> + if (is_dir_sep(*name)) {> + name++;> + break;> + }> +	}> +	else> + name = path + len2;Style:
(1) Missing SP between 'if' and '(len'.
(2) 'else' sits on the same line as '}' that closes the 'if'
clause.
(3) When any one branch of an 'if'...'else if'...'else' cascade
needs a pair of braces to group multiple statements, all other
branches must use braces as well.
Taken together:
if (len) {
...
} else {
...
}
As for what the patch intends to do, setting 'name = path + len2'
when 'len' is 0 breaks when 'path' consists only of directory
separators (for example, "/" or "///"), no?
In that case, 'len2' is positive (for example, 3) while 'len' is 0.
In add_worktree(), 'path + len - name' evaluates to (path + 0) -
(path + 3) = -3. Passed as size_t to strbuf_add(), this wraps
around to SIZE_MAX - 2 (approx. 18 exabytes), leading to a buffer
allocation failure or a crash.
Rather than calculating 'path - 1' out of bounds or introducing
'len2', worktree_basename() can simply keep 'name = path' when 'len'
is 0. Using an integer index loop 'for (int i = len - 1; 0 <= i;
i--)' avoids pointer arithmetic before the start of the buffer
entirely, I would think. Or am I missing something?
Thanks.

@gitgitgadgetgitgitgadgetBotJul 31, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

René Scharfe wrote on the Git mailing list (how to reply to this email):

On 7/25/26 6:51 PM, Junio C Hamano wrote:
> "Matthias Aßhauer via GitGitGadget" <gitgitgadget@gmail.com> writes:>>> `worktree_basename` tries to read from memory before the passed `path`>> string, if `path` is empty (or only consists of directory separators).>> That results in unexpected nonsense data being returned to the caller,>> which can lead to issues, such as `git worktree add ""` recursively>> deleting the current working directory, including `.git`.>> OK, so you do want to handle a case where path is something silly> like "///".>>> Stop reading out of bounds in these cases to avoid that behaviour.>>>> This leads to `git worktree add ""` consistently exiting with the>> message `BUG: How come '' becomes empty after sanitization?`, which is>> still undesirable, but at least it doesn't result in data loss anymore.>> OK.>>> diff --git a/builtin/worktree.c b/builtin/worktree.c>> index 4bc7b4f6e7..d8188035db 100644>> --- a/builtin/worktree.c>> +++ b/builtin/worktree.c>> @@ -297,17 +297,21 @@ static void remove_junk_on_signal(int signo)>> static const char *worktree_basename(const char *path, int *olen)>> {>> const char *name;>> -	int len;>> +	int len, len2;>> >> -	len = strlen(path);>> +	len2 = len = strlen(path);>> while (len && is_dir_sep(path[len - 1]))>> len--;>> These two 'len' variables should have clear names to distinguish> what each length represents. Rather than introducing a cryptic> 'len2', give it a more meaningful name, and rename 'len' as well if> necessary.>> I suspect that it is to remember the original length of the 'path'> before stripping the trailing directory separators?>>> -	for (name = path + len - 1; name > path; name--)>> - if (is_dir_sep(*name)) {>> - name++;>> - break;>> - }>> When 'len' is 0, the original code sets 'name' to '&path[-1]' and> does not enter the loop. However, '*olen' is set to 0, and 'name',> pointing before the start of the string, is returned. If left> unfixed, callers pass it to xstrndup(), strbuf_add(), and the like,> reading memory before the start of the string, which is horrible and> worth fixing.>>> +	if(len) {>> + for (name = path + len - 1; name > path; name--)>> + if (is_dir_sep(*name)) {>> + name++;>> + break;>> + }>> +	}>> +	else>> + name = path + len2;>> Style:>> (1) Missing SP between 'if' and '(len'.>> (2) 'else' sits on the same line as '}' that closes the 'if'> clause.>> (3) When any one branch of an 'if'...'else if'...'else' cascade> needs a pair of braces to group multiple statements, all other> branches must use braces as well.>> Taken together:>> if (len) {> ...> } else {> ...> }>> As for what the patch intends to do, setting 'name = path + len2'> when 'len' is 0 breaks when 'path' consists only of directory> separators (for example, "/" or "///"), no?>> In that case, 'len2' is positive (for example, 3) while 'len' is 0.> In add_worktree(), 'path + len - name' evaluates to (path + 0) -> (path + 3) = -3. Passed as size_t to strbuf_add(), this wraps> around to SIZE_MAX - 2 (approx. 18 exabytes), leading to a buffer> allocation failure or a crash.>> Rather than calculating 'path - 1' out of bounds or introducing> 'len2', worktree_basename() can simply keep 'name = path' when 'len'> is 0. Using an integer index loop 'for (int i = len - 1; 0 <= i;> i--)' avoids pointer arithmetic before the start of the buffer> entirely, I would think. Or am I missing something?
Interesting. This function has two types of callers. add_worktree()
does:
name = worktree_basename(path, &len);
strbuf_add(&sb, name, path + len - name);
While dwim_branch() and add() do basically:
name = worktree_basename(path, &len);
copy = xstrndup(name, len);
If path is empty or all separators, len is 0 and name invalid, as noted.
add_worktree() breaks, the other callers are mostly fine because
xstrndup() calls memchr(3) and memcpy(3) with a size of 0 internally
and thus doesn't dereference the pointer in practice. So patch 2 should
suffice to prevent the out of bounds read.
If path contains one component ("foo/"), add_worktree() adds "foo" to
the strbuf and the others similarly duplicate "foo". OK.
If path contains more components ("foo/bar/"), add_worktree() adds
"bar", while the others duplicate "bar/", because len is the length of
path without any trailing separator (7 in this example).
xstrndup("bar/", 7) could read out of bounds because it's calling
memchr(3) internally, which doesn't have to stop at the found byte. But
more practically, do we really want to keep trailing separators?
worktree_basename() would be harder to misuse if it gave the length of
the basename instead. Then add_worktree() wouldn't have to do any
pointer arithmetic and the others wouldn't risk reading out of bounds.
René

{
const char *name;
int len;
int len, len2;

len = strlen(path);
len2 = len = strlen(path);
while (len && is_dir_sep(path[len - 1]))
len--;

for (name = path + len - 1; name > path; name--)
if (is_dir_sep(*name)) {
name++;
break;
}
if(len) {
for (name = path + len - 1; name > path; name--)
if (is_dir_sep(*name)) {
name++;
break;
}
}
else
name = path + len2;

*olen = len;
return name;
Expand DownExpand Up@@ -492,6 +496,8 @@ static int add_worktree(const char *path, const char *refname,
die(_("invalid reference: %s"), refname);

@gitgitgadgetgitgitgadgetBotAug 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

René Scharfe wrote on the Git mailing list (how to reply to this email):

On 7/25/26 1:19 PM, Matthias AÃhauer via GitGitGadget wrote:
> From: =?UTF-8?q?Matthias=20A=C3=9Fhauer?= <mha1993@live.de>>> `git worktree add ""` errors out with the message `BUG: How come ''> becomes empty after sanitization?`, but not due to a bug in the> sanitization code. An empty string should remain empty during> sanitization. Instead reject the argument as invalid user input,> if it's already empty before sanitization.>> Signed-off-by: Matthias Aßhauer <mha1993@live.de>> ---> builtin/worktree.c | 2 ++> 1 file changed, 2 insertions(+)>> diff --git a/builtin/worktree.c b/builtin/worktree.c> index d8188035db..113dbf98d3 100644> --- a/builtin/worktree.c> +++ b/builtin/worktree.c> @@ -496,6 +496,8 @@ static int add_worktree(const char *path, const char *refname,> die(_("invalid reference: %s"), refname);>> name = worktree_basename(path, &len);> +	if (!len)> + die(_("the empty string is not a valid worktree"));> strbuf_add(&sb, name, path + len - name);> sanitize_refname_component(sb.buf, &sb_name);> if (!sb_name.len)
Hmm, on my machine, with or without this patch:
$ git worktree add ""
Preparing worktree (new branch '')
fatal: '' is not a valid branch name
hint: See 'git help check-ref-format'
hint: Disable this message with "git config set advice.refSyntax false"
and
$ git worktree add /
Preparing worktree (new branch '')
fatal: '' is not a valid branch name
hint: See 'git help check-ref-format'
hint: Disable this message with "git config set advice.refSyntax false"
This error message is produced by the command 'git branch "" HEAD'
issued using run_command() in add(), just before the the add_worktree()
call, which is then skipped.
René

@gitgitgadgetgitgitgadgetBotAug 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

René Scharfe wrote on the Git mailing list (how to reply to this email):

On 8/2/26 8:26 AM, René Scharfe wrote:
> On 7/25/26 1:19 PM, Matthias AÃhauer via GitGitGadget wrote:>> From: =?UTF-8?q?Matthias=20A=C3=9Fhauer?= <mha1993@live.de>>>>> `git worktree add ""` errors out with the message `BUG: How come ''>> becomes empty after sanitization?`, but not due to a bug in the>> sanitization code. An empty string should remain empty during>> sanitization. Instead reject the argument as invalid user input,>> if it's already empty before sanitization.>>>> Signed-off-by: Matthias Aßhauer <mha1993@live.de>>> --->> builtin/worktree.c | 2 ++>> 1 file changed, 2 insertions(+)>>>> diff --git a/builtin/worktree.c b/builtin/worktree.c>> index d8188035db..113dbf98d3 100644>> --- a/builtin/worktree.c>> +++ b/builtin/worktree.c>> @@ -496,6 +496,8 @@ static int add_worktree(const char *path, const char *refname,>> die(_("invalid reference: %s"), refname);>> >> name = worktree_basename(path, &len);>> +	if (!len)>> + die(_("the empty string is not a valid worktree"));>> strbuf_add(&sb, name, path + len - name);>> sanitize_refname_component(sb.buf, &sb_name);>> if (!sb_name.len)>> Hmm, on my machine, with or without this patch:>> $ git worktree add ""> Preparing worktree (new branch '')> fatal: '' is not a valid branch name> hint: See 'git help check-ref-format'> hint: Disable this message with "git config set advice.refSyntax false"
This hits the BUG by passing the empty string directly to add_worktree():
$ git worktree add "" HEAD
Preparing worktree (detached HEAD a97fcc37c2)
BUG: builtin/worktree.c:498: How come '' becomes empty after sanitization?
René


name = worktree_basename(path, &len);
if (!len)
die(_("the empty string is not a valid worktree"));
strbuf_add(&sb, name, path + len - name);
sanitize_refname_component(sb.buf, &sb_name);
if (!sb_name.len)
Expand Down
Loading