Gentoo Linux — app-containers/docker — multiple vulnerabilities (13 CVEs) — patch and remediation guide

📖 ~4 min read  •  Source: Gentoo GLSA GLSA-202409-29

Related CVEs: CVE-2021-41089 CVE-2021-41091 CVE-2022-36109 CVE-2022-41717 CVE-2023-26054 CVE-2023-28840 CVE-2023-28841 CVE-2023-28842  +5 more

Upstream summary: Multiple vulnerabilities have been discovered in Docker. Please review the CVE identifiers referenced below for details.

Table of contents

1. Symptom & Impact
2. Environment & Reproduction
3. Root Cause Analysis
4. Quick Triage
5. Step-by-Step Diagnosis
6. Solution – Primary Fix
7. Solution – Alternative Approaches
8. Verification & Acceptance Criteria
9. Rollback Plan
10. Prevention & Hardening
11. Related Errors & Cross-Refs
12. References & Further Reading

Symptom & Impact

app-containers/docker runs when an image is pulled, unpacked, inspected or a container is started, so a defect here is normally reached through untrusted image content or a registry response rather than inbound traffic to a listening port. On Gentoo Linux that shows up as escapes from the container’s namespaces, files written outside the intended root during buildah or podman build, mount and capability handling that grants more than was requested, and images produced before the update carrying the defect onward to every host that pulls them. app-containers/docker is container tooling — command-line binaries invoked per operation, though a node runtime such as cri-o does run as a unit — so restart steps apply to that runtime and to containers still running the old code, not to app-containers/docker itself.

Environment & Reproduction

Reproduction targets Gentoo Linux (rolling release; Portage). Confirm release, profile, and the installed package via Portage tooling:

cat /etc/gentoo-release
cat /etc/os-release
eselect profile show
equery list app-containers/docker
equery files app-containers/docker | head -40
eix app-containers/docker 2>/dev/null || qlist -I app-containers/docker

Exercise the workload that uses app-containers/docker while collecting:

# Branch on init system: systemd vs OpenRC
if [ -d /run/systemd/system ]; then 
  sudo journalctl -u docker -b --no-pager | tail -200; 
else 
  sudo tail -200 /var/log/rc.log; sudo rc-status --all; 
fi
sudo tail -200 /var/log/emerge.log
sudo tail -200 /var/log/messages 2>/dev/null || sudo journalctl -xe --no-pager | tail -200
# Hardened/SELinux profiles only:

Root Cause Analysis

Root cause is documented in Gentoo GLSA GLSA-202409-29. Gentoo maintainers shipped fixed ebuilds for app-containers/docker; running an outdated build leaves the host exposed to the failure modes described in the advisory. Because Gentoo is source-based, the relevant change is a SLOT bump or a USE-flag-conditional patch — correlate Portage history with system logs:

sudo tail -200 /var/log/emerge.log
genlop -t app-containers/docker 2>/dev/null | tail -40   # if app-portage/genlop is merged
equery changes app-containers/docker 2>/dev/null | tail -40
equery uses app-containers/docker                         # USE flags that affect the build
sudo glsa-check -l affected | head
cat /proc/sys/kernel/tainted              # non-zero = tainted kernel / out-of-tree modules

Quick Triage

Run these on Gentoo Linux to capture the current state of app-containers/docker:

qlist -Iv app-containers/docker                                   # installed version(s)
equery list app-containers/docker                                 # all installed SLOTs
equery check app-containers/docker 2>/dev/null || qcheck app-containers/docker    # verify shipped files
sudo glsa-check -l affected
sudo glsa-check -p GLSA-202409-29            # preview this advisory fix
# Init system aware service / firewall checks:
if [ -d /run/systemd/system ]; then 
  systemctl --failed --no-pager; 
else 
  sudo rc-status --servicelist 2>&1 | grep -E 'crashed|stopped' || sudo rc-status --all; 
fi
sudo nft list ruleset 2>/dev/null | head -50 || sudo iptables -S 2>/dev/null | head -50
# Hardened/SELinux profile only:
# If docker ships a service unit (unit name may differ from pkg name, e.g.
# bind→named, postgresql→postgresql-N.M, php-fpm→php-fpm):
systemctl list-unit-files 2>/dev/null | grep -i docker | head || 
  ls /etc/init.d/ | grep -i docker | head

Step-by-Step Diagnosis

1. Enumerate failed services across either init system.

   if [ -d /run/systemd/system ]; then systemctl --failed --no-pager; 
   else sudo rc-status --servicelist | grep -E 'crashed|stopped'; fi

2. Tail logs for app-containers/docker on the host’s init system.

   if [ -d /run/systemd/system ]; then 
     sudo journalctl -u docker -f --no-pager; 
   else 
     sudo tail -F /var/log/docker/*.log 2>/dev/null; sudo tail -F /var/log/messages; 
   fi

3. Inspect firewall posture (nftables / iptables).

   sudo nft list ruleset 2>/dev/null | head -80
   sudo iptables -S 2>/dev/null | head -80
   sudo ip6tables -S 2>/dev/null | head -40

4. On hardened/SELinux profiles, surface denials and author a local policy module.

   command -v ausearch >/dev/null || { echo 'no audit (default profile)'; exit 0; }

5. Verify app-containers/docker integrity and re-merge if anything is altered.

   sudo equery check app-containers/docker 2>/dev/null || sudo qcheck app-containers/docker
   sudo emerge -1 app-containers/docker                       # one-shot rebuild
   sudo revdep-rebuild -i -- -av app-containers/docker        # rebuild reverse-deps if ABI shifted

6. Correlate findings with /var/log/emerge.log, genlop -t app-containers/docker, and Gentoo GLSA GLSA-202409-29 to pin the change that introduced the regression.

Solution – Primary Fix

Apply the corrective Portage transaction referenced by Gentoo GLSA GLSA-202409-29, then reload affected services on whichever init system this host uses:

sudo emerge --sync                                 # or: sudo emaint --auto sync
sudo emerge -avuDN @world                          # deep, --newuse, --update
# Or fix just this advisory:
sudo glsa-check -p GLSA-202409-29             # preview what will change
sudo glsa-check -f GLSA-202409-29             # apply the GLSA fix
# Or target just the affected package (oneshot avoids world-set churn):
sudo emerge --update --oneshot app-containers/docker
sudo emerge --depclean -a                          # drop now-orphaned deps
# Restart the affected service via the host's init system:
if [ -d /run/systemd/system ]; then 
  sudo systemctl daemon-reload; 
  systemctl list-unit-files | grep -i docker | head; 
  sudo systemctl restart docker; 
  systemctl is-active docker 2>/dev/null; 
else 
  ls /etc/init.d/ | grep -i docker | head; 
  sudo rc-service docker restart; 
  sudo rc-status | grep -i docker; 
fi
qlist -Iv app-containers/docker                                    # confirm new version

For kernel advisories on sys-kernel/gentoo-sources, sys-kernel/gentoo-kernel, or sys-kernel/gentoo-kernel-bin, rebuild the kernel and reboot:

sudo emerge --update --oneshot sys-kernel/gentoo-kernel-bin   # binary path (no rebuild)
# OR rebuild a source-based kernel after eselect-pinning the new sources:
sudo eselect kernel list
sudo eselect kernel set 1
sudo emerge --config sys-kernel/gentoo-kernel       # rebuild + install image/initramfs
sudo emerge --ask sys-kernel/dracut sys-kernel/installkernel
sudo grub-mkconfig -o /boot/grub/grub.cfg           # if using GRUB
sudo systemctl reboot 2>/dev/null || sudo shutdown -r now

Solution – Alternative Approaches

If the primary patch is not viable, choose from these:

• Toggle USE flags rather than upgrading (when the GLSA recommends disabling a vulnerable feature):

  equery uses app-containers/docker
  sudo euse -E <flag>                              # gentoolkit: enable globally
  sudo euse -D <flag>                              # gentoolkit: disable globally
  # Or per-package in /etc/portage/package.use/docker:
  echo 'app-containers/docker -<flag>' | sudo tee -a /etc/portage/package.use/docker
  sudo emerge -avuDN @world

• Roll back to a known-good ebuild version via package.mask and binhost cache:

  sudo tee -a /etc/portage/package.mask <<<'>=app-containers/docker-<bad-ver>'
  sudo emerge --oneshot --update app-containers/docker
  # Or pull a binary from your binhost (PORTAGE_BINHOST):
  sudo emerge --getbinpkgonly app-containers/docker

• Unmask a higher-version fix from ~arch (testing) when stable is lagging:

  sudo tee -a /etc/portage/package.accept_keywords <<<'app-containers/docker ~amd64'
  sudo emerge --update --oneshot app-containers/docker

• On hardened / SELinux profiles, switch to permissive briefly to confirm policy is the cause, then re-enforce:

  # reproduce, capture denials, author a custom module:

• Take an LVM snapshot before a world upgrade for fast rollback:

  sudo lvs
  sudo lvcreate -s -n preupgrade -L 4G /dev/<vg>/<lv>
  # revert later via:
  sudo lvconvert --merge /dev/<vg>/preupgrade && sudo reboot

• Stage the upgrade on a non-prod chroot or use a binhost (binary package host) so production hosts pull a pre-built fixed ebuild:

  # On the build host:
  sudo emerge --buildpkg --oneshot app-containers/docker
  # /etc/portage/make.conf on the build host:
  #   FEATURES="buildpkg"
  #   PKGDIR="/srv/binpkgs"
  # On consumer hosts, set PORTAGE_BINHOST and pull:
  sudo emerge --getbinpkgonly --update app-containers/docker

Verification & Acceptance Criteria

All of these should pass after the fix:

qlist -Iv app-containers/docker                                            # expected fixed version
sudo glsa-check -l affected                                # this GLSA no longer listed
sudo glsa-check -t all                                     # test ALL outstanding GLSAs
if [ -d /run/systemd/system ]; then 
  systemctl is-active docker 2>/dev/null; 
  sudo journalctl -u docker --since "5 minutes ago" --no-pager | grep -iE "error|fail" || echo OK; 
else 
  sudo rc-status | grep -i docker; 
fi
sudo nft list ruleset 2>/dev/null | head -20 || sudo iptables -S | head -20
sudo emerge --info | head -20                              # profile + USE flags snapshot

The conditions described in the advisory must no longer be reported for app-containers/docker across two consecutive runs.

Rollback Plan

Capture state before any change:

qlist -Iv > /root/portage-pre.txt
sudo cp -a /var/db/pkg /root/var-db-pkg-pre        # full package metadata snapshot
sudo cp -a /etc/portage /root/etc-portage-pre
# Optional LVM snapshot of the root LV:
sudo lvcreate -s -n preupgrade -L 4G /dev/<vg>/<lv>

To revert if the patch is bad:

# Pull the previous binpkg from your binhost (if FEATURES=buildpkg is enabled):
sudo emerge --getbinpkgonly --oneshot =app-containers/docker-<older-ver>
# Or mask the bad version so emerge picks the older slot:
sudo tee -a /etc/portage/package.mask <<<'>=app-containers/docker-<bad-ver>'
sudo emerge --oneshot app-containers/docker
# Restart the service on whichever init system is in use:
if [ -d /run/systemd/system ]; then 
  sudo systemctl daemon-reload; 
  sudo systemctl restart docker; 
else 
  sudo rc-service docker restart; 
fi
# Or merge the LVM snapshot and reboot:
sudo lvconvert --merge /dev/<vg>/preupgrade && sudo reboot
# Custom SELinux policy cleanup (hardened profile only):

Prevention & Hardening

Reduce the chance of this recurring on Gentoo Linux:

• Automate GLSA + world checks (cron / systemd timer):

  sudo emerge -av app-portage/gentoolkit app-portage/eix
  # Cron example (daily 03:00):
  sudo tee /etc/cron.daily/gentoo-security <<'SH'
  #!/bin/sh
  set -e
  emaint --auto sync >/dev/null
  glsa-check -l affected | tee /var/log/glsa-affected.log
  SH
  sudo chmod +x /etc/cron.daily/gentoo-security

• Subscribe to security.gentoo.org/glsa and the Gentoo news feed for upstream advisories.

• Run a local binhost for controlled rollouts across a Gentoo fleet (one build host, many consumers):

  # On the build host /etc/portage/make.conf:
  FEATURES="${FEATURES} buildpkg"
  PKGDIR="/srv/binpkgs"
  # Then publish /srv/binpkgs over HTTPS and set on consumers:
  PORTAGE_BINHOST="https://binhost.example.com/binpkgs/"
  FEATURES="${FEATURES} getbinpkg"

• Mask sensitive packages so they cannot be auto-upgraded without review:

  sudo tee -a /etc/portage/package.mask <<<'>app-containers/docker-<pinned-ver>'
  sudo tee -a /etc/portage/package.accept_keywords <<<'app-containers/docker ~amd64'

• Monitor file integrity with AIDE:

  sudo emerge -av app-forensics/aide
  sudo aide --init && sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  sudo aide --check

• Consider the hardened profile (or hardened/selinux) where threat model warrants it:

  sudo eselect profile list | grep -i hardened
  sudo eselect profile set <hardened-profile-number>
  sudo emerge -avuDN @world                          # rebuild world against new profile

• Keep revdep-rebuild clean after every world upgrade, and rebuild downstream consumers of upgraded libs.

• Apply CIS Linux Benchmark hardening (where applicable) and remove unused USE flags / packages.

Related Errors & Cross-Refs

Issues that commonly surface alongside a app-containers/docker update: Portage lock contention, USE-flag dependency cycles (blockers), revdep ABI mismatches, OpenRC / systemd unit ordering issues, and kernel taint flags. Useful triage:

sudo emerge --info | head
sudo emerge -puDN @world | tail -40                # preview pending updates
sudo revdep-rebuild -i -- -p                       # show broken libraries
sudo eix-test-obsolete                             # repo / overlay drift
cat /proc/sys/kernel/tainted
sudo glsa-check -l affected

View all gentoo-linux tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Primary reference: Gentoo GLSA GLSA-202409-29. Manual pages useful on Gentoo Linux:

man emerge
man portage
man glsa-check
man equery
man eix
man rc-service
man rc-update
man systemctl
man journalctl
man dispatch-conf
man revdep-rebuild

Other resources: wiki.gentoo.org, Gentoo GLSA index, packages.gentoo.org, and per-package notes in /usr/share/doc/docker/ for components implicated in this advisory.

View all Gentoo Linux tutorials on the Tutorials Hub →