docker-credential-helpers: docker-credential-helpers segfaults (free(): invalid pointer) if list() fails

https://github.com/docker/docker-credential-helpers/blob/19b711cc92fbaa47533646fa8adb457d199c99e1/secretservice/secretservice_linux.go#L96 The wrong free() function is used here - it needs to call g_error_free(err) instead of free, as it does on e.g. line 72. This has caused several crashes in the wild: see for example https://github.com/moby/moby/issues/34048, https://github.com/docker/for-linux/issues/185, https://github.com/elastic/elasticsearch-docker/issues/163, and I most recently ran into this issue myself on a build machine.

There is an active PR to fix this issue (#29) and another issue (#23) but neither has had any activity in nearly 2 years. The PR is good - please merge it.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 6
  • Comments: 19 (1 by maintainers)

Commits related to this issue

Most upvoted comments

I just ran into this issue. I used the latest Ubuntu 18.04 image for an AWS instance, and then installed Docker CE.

EDIT: The below may still be useful to some but I think the real issue is installing docker-compose which has a dependency on golang-docker-credential-helpers in the ubuntu bionic repo. That is an old version of docker-compose anyway (1.17.1). Remove it and the golang-docker-credential-helpers and install the latest docker-compose (currently 1.23.1) using these instructions.


I also installed docker-compose from the bionic repository. This is the package that depends on the golang-docker-credential-helpers package which seems to be causing the issue. As I need docker-compose I didn’t want to uninstall golang-docker-credential-helpers. As @nneonneo said above, there is no release that contains the fix, but it has been merged to the master branch of docker-credential-helpers.

You’ll have to build it from sources for which you’ll need go (snap install go --classic) and pkg-config(apt-get install pkg-config). Follow the readme to get the sources and then make secretservice.

Lastly I put the resulting binary in /usr/local/bin which is on the path ahead of /usr/bin.

After all of that the error no longer happens. I hope this helps others until a new release is created and put in the bionic repo.

Is there any other workaround for this?

As far as I can tell, this issue has been fixed in 73e5f5d. If you’re running into the issue, try building it from source and testing again.

The maintainers should make a new release, so that fixed versions can eventually propagate to downstream repositories.