* Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent
@ 2024-06-19 19:53 Mike Hommey
2024-06-19 20:44 ` Jeff King
0 siblings, 1 reply; 3+ messages in thread
From: Mike Hommey @ 2024-06-19 19:53 UTC (permalink / raw)
To: git
Hi,
I actually found this a few years ago, but didn't worry too much about
it, forgot about it, then rediscovered it yesterday. I tried to untangle
the situation, but it looks like it would take me more time than I can
allocate, so I'm sending this report.
When you call `remote_get(name)`, you may end up giving ownership of
`name` to the remote, such that if you `free(name)`, using the remote
after that may lead to use-after-free. Of course, this is a
use-libgit-as-a-library situation; I don't think it happens in actual
git code.
Here's how it goes: if your `name` is actually a URL, you end up in this
case in remotes_remote_get_1:
if (name_given && !valid_remote(ret))
add_url_alias(remote_state, ret, name);
`add_url_alias` will eventually set `ret->url` to contain `name` as-is,
taking ownership. Later `release_clear` will free it, which will lead to
double-free if the caller frees it.
It's further complicated by `add_url_alias` also sometimes *not* taking
ownership, in the face of URL rewrites (in `alias_url`). Meaning, the
fix is not as straightforward as changing the above to
add_url_alias(remote_state, ret, xstrdup(name));
This is as far as I went before my time was up on this issue.
Mike
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent
2024-06-19 19:53 Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent Mike Hommey
@ 2024-06-19 20:44 ` Jeff King
2024-06-19 21:24 ` Mike Hommey
0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2024-06-19 20:44 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
On Thu, Jun 20, 2024 at 04:53:11AM +0900, Mike Hommey wrote:
> When you call `remote_get(name)`, you may end up giving ownership of
> `name` to the remote, such that if you `free(name)`, using the remote
> after that may lead to use-after-free. Of course, this is a
> use-libgit-as-a-library situation; I don't think it happens in actual
> git code.
Try this recent series:
https://lore.kernel.org/git/20240614102439.GA222287@coredump.intra.peff.net/
especially patches 2 and 3. Junio has it queued as jk/remote-wo-url.
Also, you might want to check the later patches to make sure the
cleanups don't cause any problems for your use case.
-Peff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent
2024-06-19 20:44 ` Jeff King
@ 2024-06-19 21:24 ` Mike Hommey
0 siblings, 0 replies; 3+ messages in thread
From: Mike Hommey @ 2024-06-19 21:24 UTC (permalink / raw)
To: Jeff King; +Cc: git
On Wed, Jun 19, 2024 at 04:44:50PM -0400, Jeff King wrote:
> On Thu, Jun 20, 2024 at 04:53:11AM +0900, Mike Hommey wrote:
>
> > When you call `remote_get(name)`, you may end up giving ownership of
> > `name` to the remote, such that if you `free(name)`, using the remote
> > after that may lead to use-after-free. Of course, this is a
> > use-libgit-as-a-library situation; I don't think it happens in actual
> > git code.
>
> Try this recent series:
>
> https://lore.kernel.org/git/20240614102439.GA222287@coredump.intra.peff.net/
>
> especially patches 2 and 3. Junio has it queued as jk/remote-wo-url.
> Also, you might want to check the later patches to make sure the
> cleanups don't cause any problems for your use case.
What timing! It looks like both these two patches address my issue
without breaking anything for me.
Thanks
Mike
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-06-19 21:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-19 19:53 Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent Mike Hommey
2024-06-19 20:44 ` Jeff King
2024-06-19 21:24 ` Mike Hommey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox