Gentoo Linux — app-arch/lz4 — vulnerability — patch and remediation guide

📖 ~4 min read  •  Source: Gentoo GLSA GLSA-202406-04

Related CVEs: CVE-2021-3520

Upstream summary: An attacker who submits a crafted file to an application linked with lz4 may be able to trigger an integer overflow, leading to calling of memmove() on a negative size argument, causing an out-of-bounds write and/or a crash.

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

On Gentoo Linux hosts that have app-arch/lz4 merged from the Portage tree, operators report behaviour consistent with Gentoo GLSA GLSA-202406-04: emerge flags the package as affected by the GLSA, glsa-check lists the advisory as unresolved, and — for security-rated advisories — the host is exposed to the vulnerability set above. Impact ranges from a single OpenRC / systemd unit restart loop to wider availability incidents whenever app-arch/lz4 sits on the serving path of the workstation, build host, or binhost.

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-arch/lz4
equery files app-arch/lz4 | head -40
eix app-arch/lz4 2>/dev/null || qlist -I app-arch/lz4

Trigger the workflow that exposes app-arch/lz4 — vulnerability — patch and remediation guide while collecting:

# Branch on init system: systemd vs OpenRC
if [ -d /run/systemd/system ]; then 
  sudo journalctl -u lz4 -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:
sudo ausearch -m AVC,USER_AVC -ts today 2>/dev/null | tail -100 || echo 'no audit log (non-hardened profile)'

Root Cause Analysis

Root cause is documented in Gentoo GLSA GLSA-202406-04. Gentoo maintainers shipped fixed ebuilds for app-arch/lz4; 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-arch/lz4 2>/dev/null | tail -40   # if app-portage/genlop is merged
equery changes app-arch/lz4 2>/dev/null | tail -40
equery uses app-arch/lz4                         # 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-arch/lz4:

qlist -Iv app-arch/lz4                                   # installed version(s)
equery list app-arch/lz4                                 # all installed SLOTs
equery check app-arch/lz4 2>/dev/null || qcheck app-arch/lz4    # verify shipped files
sudo glsa-check -l affected
sudo glsa-check -p GLSA-202406-04            # 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:
command -v getenforce >/dev/null && getenforce && sestatus || echo 'SELinux not enabled (default profile)'
# If lz4 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 lz4 | head || 
  ls /etc/init.d/ | grep -i lz4 | 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-arch/lz4 on the host’s init system.

   if [ -d /run/systemd/system ]; then 
     sudo journalctl -u lz4 -f --no-pager; 
   else 
     sudo tail -F /var/log/lz4/*.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; }
   sudo ausearch -m AVC,USER_AVC -ts today
   sudo ausearch -m AVC -ts today | audit2allow -a -M /tmp/local-fix
   sudo semodule -i /tmp/local-fix.pp

5. Verify app-arch/lz4 integrity and re-merge if anything is altered.

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

6. Correlate findings with /var/log/emerge.log, genlop -t app-arch/lz4, and Gentoo GLSA GLSA-202406-04 to pin the change that introduced app-arch/lz4 — vulnerability — patch and remediation guide.

Solution – Primary Fix

Apply the corrective Portage transaction referenced by Gentoo GLSA GLSA-202406-04, 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-202406-04             # preview what will change
sudo glsa-check -f GLSA-202406-04             # apply the GLSA fix
# Or target just the affected package (oneshot avoids world-set churn):
sudo emerge --update --oneshot app-arch/lz4
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 lz4 | head; 
  sudo systemctl restart lz4; 
  systemctl is-active lz4 2>/dev/null; 
else 
  ls /etc/init.d/ | grep -i lz4 | head; 
  sudo rc-service lz4 restart; 
  sudo rc-status | grep -i lz4; 
fi
qlist -Iv app-arch/lz4                                    # 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-arch/lz4
  sudo euse -E <flag>                              # gentoolkit: enable globally
  sudo euse -D <flag>                              # gentoolkit: disable globally
  # Or per-package in /etc/portage/package.use/lz4:
  echo 'app-arch/lz4 -<flag>' | sudo tee -a /etc/portage/package.use/lz4
  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-arch/lz4-<bad-ver>'
  sudo emerge --oneshot --update app-arch/lz4
  # Or pull a binary from your binhost (PORTAGE_BINHOST):
  sudo emerge --getbinpkgonly app-arch/lz4

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

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

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

  sudo setenforce 0
  # reproduce, capture denials, author a custom module:
  sudo ausearch -m AVC -ts recent | audit2allow -a -M mylocal
  sudo semodule -i mylocal.pp
  sudo setenforce 1

• 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-arch/lz4
  # /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-arch/lz4

Verification & Acceptance Criteria

All of these should pass after the fix:

qlist -Iv app-arch/lz4                                            # 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 lz4 2>/dev/null; 
  sudo journalctl -u lz4 --since "5 minutes ago" --no-pager | grep -iE "error|fail" || echo OK; 
else 
  sudo rc-status | grep -i lz4; 
fi
sudo nft list ruleset 2>/dev/null | head -20 || sudo iptables -S | head -20
command -v getenforce >/dev/null && getenforce || true
sudo emerge --info | head -20                              # profile + USE flags snapshot

The original reproduction for app-arch/lz4 — vulnerability — patch and remediation guide must not trigger 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-arch/lz4-<older-ver>
# Or mask the bad version so emerge picks the older slot:
sudo tee -a /etc/portage/package.mask <<<'>=app-arch/lz4-<bad-ver>'
sudo emerge --oneshot app-arch/lz4
# Restart the service on whichever init system is in use:
if [ -d /run/systemd/system ]; then 
  sudo systemctl daemon-reload; 
  sudo systemctl restart lz4; 
else 
  sudo rc-service lz4 restart; 
fi
# Or merge the LVM snapshot and reboot:
sudo lvconvert --merge /dev/<vg>/preupgrade && sudo reboot
# Custom SELinux policy cleanup (hardened profile only):
sudo semodule -r mylocal

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-arch/lz4-<pinned-ver>'
  sudo tee -a /etc/portage/package.accept_keywords <<<'app-arch/lz4 ~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 app-arch/lz4 — vulnerability — patch and remediation guide: 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-202406-04. 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/lz4/ for components implicated in app-arch/lz4 — vulnerability — patch and remediation guide.

View all Gentoo Linux tutorials on the Tutorials Hub →