threads / discuss / 61652

Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent

Subject: Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent

## tl;dr

3 messages between Jun 19, 2024 and Jun 19, 2024.

replies: 2people: 2as markdown or json

Mike Hommey· Jun 19, 2024, 19:53 UTC · lore

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

Jeff King· Jun 19, 2024, 20:44 UTC · re: Mike Hommey · lore

Re: Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent

On Thu, Jun 20, 2024 at 04:53:11AM +0900, Mike Hommey wrote:

Show 5 quoted lines

> 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

Mike Hommey· Jun 19, 2024, 21:24 UTC · re: Jeff King · lore

Re: Ownership handling of the "remote name" buffer given to `remote_get` is inconsistent

On Wed, Jun 19, 2024 at 04:44:50PM -0400, Jeff King wrote:

Show 15 quoted lines

> 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