Alpine Linux 3.18 — libslirp — multiple vulnerabilities (8 CVEs) — patch and remediation guide

📖 ~4 min read  •  Source: Alpine secdb entry — libslirp 4.6.0-r0

Related CVEs: CVE-2021-3592 CVE-2021-3593 CVE-2021-3594 CVE-2021-3595 CVE-2020-29129 CVE-2020-29130 CVE-2020-10756 CVE-2020-1983

Upstream summary: Alpine community repository for vv3.18 ships libslirp 4.6.0-r0 which addresses CVE-2021-3592.

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 Alpine Linux 3.18 hosts that have libslirp installed, operators see behaviour consistent with Alpine secdb entry — libslirp 4.6.0-r0: apk audit --system flags the package, OpenRC services that link against libslirp log errors to /var/log/messages, and — for security-rated fixes — the host remains exposed to the CVE set above. Because Alpine is musl-based and ships in many container images, the same vulnerable build often propagates into every layer that FROM alpine:18 downstream.

Environment & Reproduction

Reproduction targets Alpine Linux 3.18. Confirm release and the installed package:

cat /etc/alpine-release
cat /etc/os-release
apk info -v libslirp
apk policy libslirp
apk version | grep -w libslirp || true

Trigger the workflow that exposes libslirp — multiple vulnerabilities (8 CVEs) — patch and remediation guide while collecting:

sudo tail -200 /var/log/messages       # busybox syslog / syslog-ng
sudo dmesg | tail -200
sudo rc-service libslirp status 2>/dev/null || true
sudo rc-status
sudo apk audit --system

Root Cause Analysis

Root cause is recorded in Alpine secdb entry — libslirp 4.6.0-r0. Alpine maintainers shipped the fix in 4.6.0-r0 for Alpine Linux 3.18; running an older build leaves the host exposed. Correlate apk transactions with the kernel ring buffer and OpenRC logs:

sudo tail -200 /var/log/apk.log
apk info -v libslirp
apk info -L libslirp | head
sudo dmesg --ctime | tail -100
ls -lt /var/log/rc.log 2>/dev/null && sudo tail -100 /var/log/rc.log

Quick Triage

Run these on Alpine Linux 3.18 to capture the current state of libslirp:

apk info -v libslirp                       # installed version
apk policy libslirp                        # repository / pin info
apk version -l '<'                       # all packages with newer candidates
sudo apk audit --system
apk info -L libslirp | head                # files shipped by libslirp
sudo rc-status                           # OpenRC runtime state
sudo rc-update show                      # services per runlevel
sudo iptables -L -n -v --line-numbers 2>/dev/null | head -40
sudo nft list ruleset 2>/dev/null | head -40
# If libslirp ships an OpenRC service (init name may differ from pkg name,
# e.g. nginx, postgresql, php-fpm83):
ls /etc/init.d/ | grep -i libslirp | head

Step-by-Step Diagnosis

1. List OpenRC services and any failed ones.

   sudo rc-status
   sudo rc-status --crashed

2. Inspect logs for libslirp.

   sudo grep -i libslirp /var/log/messages | tail -200
   sudo dmesg | tail -200

3. Inspect firewall posture (Alpine ships iptables/nftables or the awall front-end).

   sudo iptables -L -n -v --line-numbers
   sudo nft list ruleset
   sudo awall list 2>/dev/null || true

4. Verify libslirp integrity and reinstall if files are altered.

   sudo apk verify libslirp
   sudo apk fix libslirp

5. Confirm the current vs. available version for libslirp.

   apk version | grep -w libslirp || true
   apk policy libslirp

6. Correlate findings with /var/log/apk.log and Alpine secdb entry — libslirp 4.6.0-r0 to pin the change that introduced libslirp — multiple vulnerabilities (8 CVEs) — patch and remediation guide.

Solution – Primary Fix

Apply the corrective apk transaction referenced by Alpine secdb entry — libslirp 4.6.0-r0, then restart affected OpenRC services:

sudo apk update
sudo apk upgrade --available --no-cache       # apply all repository updates
# Or target a single package:
sudo apk add --upgrade libslirp
apk info -v libslirp                              # confirm new version
sudo rc-service libslirp restart 2>/dev/null || true
sudo rc-update add libslirp default 2>/dev/null || true
sudo rc-service libslirp status 2>/dev/null || true

For kernel / musl / openssl updates a reboot is required (Alpine has no live-patching equivalent of kpatch):

apk info -v linux-lts linux-virt 2>/dev/null
sudo sync && sudo reboot
# On Alpine diskless / lbu installations, commit the change first:
sudo lbu status
sudo lbu commit -d

Solution – Alternative Approaches

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

• Roll back to a known-good version by installing a pinned version from /etc/apk/cache:

  ls /etc/apk/cache/ | head
  sudo apk add libslirp=4.6.0-r0     # downgrade / pin to a specific version
  sudo apk fix

• Hold the package so apk cannot upgrade it during the next apk upgrade:

  echo 'libslirp' | sudo tee -a /etc/apk/world
  # To pin a version, edit /etc/apk/world to read: libslirp=4.6.0-r0
  sudo apk fix

• Pull the fix from edge while staying on a stable release (tagged repo):

  echo '@edge https://dl-cdn.alpinelinux.org/alpine/edge/main' | sudo tee -a /etc/apk/repositories
  sudo apk add libslirp@edge

• Use awall to ring-fence the affected service while you patch:

  sudo apk add awall
  sudo awall list
  sudo awall enable <policy>
  sudo awall activate

• Take an lbu snapshot of /etc before kernel / musl upgrades (Alpine diskless mode):

  sudo lbu status
  sudo lbu package /var/backups/alpine-pre-upgrade.apkovl.tar.gz
  # Revert later by booting from media and restoring the apkovl tarball.

• For container deployments, rebuild the image from a patched base:

  docker run --rm alpine:18 apk version | grep -w libslirp || true
  # In your Dockerfile, force a refresh: RUN apk add --no-cache --upgrade libslirp

Verification & Acceptance Criteria

All of these should pass after the fix:

apk info -v libslirp                              # expected fixed version
sudo apk audit --system                         # the package no longer flagged
sudo apk verify libslirp
sudo rc-service libslirp status 2>/dev/null || true
sudo grep -iE 'error|fail' /var/log/messages | grep -i libslirp | tail -50 || echo OK
sudo iptables -L -n -v | head -20
sudo nft list ruleset | head -20

The original reproduction for libslirp — multiple vulnerabilities (8 CVEs) — patch and remediation guide must not trigger across two consecutive runs.

Rollback Plan

Capture state before any change:

apk info -v > /root/apk-pre.txt
sudo cp /etc/apk/world /root/world-pre
sudo cp -a /var/log/apk.log /root/apk.log-pre 2>/dev/null || true
# On lbu / diskless installs, snapshot the apkovl:
sudo lbu package /var/backups/alpine-pre-upgrade.apkovl.tar.gz

To revert if the patch is bad:

# Reinstall the previous version from /etc/apk/cache (must be mounted):
ls /etc/apk/cache/ | head
sudo apk add libslirp=<previous-version>
sudo rc-service libslirp restart 2>/dev/null || true
# Or restore the saved apkovl on diskless:
sudo tar -xzf /var/backups/alpine-pre-upgrade.apkovl.tar.gz -C /
sudo reboot

Prevention & Hardening

Reduce the chance of this recurring on Alpine Linux 3.18:

• Run apk audit --system on a schedule and fail builds on new findings:

  # /etc/periodic/daily/apk-audit
  #!/bin/sh
  apk update -q && apk audit --system > /var/log/apk-audit.log

• Mount /etc/apk/cache so previous versions are always available for rollback:

  sudo mkdir -p /etc/apk/cache
  sudo setup-apkcache /etc/apk/cache

• Subscribe to alpine-security and watch security.alpinelinux.org for new CVE entries.

• Mirror the Alpine repository locally for controlled rollouts:

  sudo apk add rsync
  rsync -av --delete rsync://rsync.alpinelinux.org/alpine/v3.20/main/ /srv/mirror/v3.20/main/
  rsync -av --delete rsync://rsync.alpinelinux.org/alpine/v3.20/community/ /srv/mirror/v3.20/community/

• Pin sensitive packages in /etc/apk/world with explicit versions so apk cannot silently bump them.

• Alpine does not enable mandatory-access-control frameworks (such as AppArmor) by default; consult [grsecurity/PaX] or [seccomp profile] in container deployments and apply CIS-style hardening for Alpine Linux 3.18 (disable unused OpenRC services, set rc_logger=YES in /etc/rc.conf, mount /tmp with nosuid,nodev).

• For container fleets, scan images in CI:

  docker run --rm alpine:18 apk version
  trivy image --severity HIGH,CRITICAL myrepo/app:tag

Related Errors & Cross-Refs

Issues that commonly surface alongside libslirp — multiple vulnerabilities (8 CVEs) — patch and remediation guide: apk lock contention (/var/lib/apk/lock), OpenRC dependency cycles, busybox applet quirks vs. coreutils, and musl-vs-glibc behavioural differences. Useful triage:

sudo apk fix
sudo rc-status --crashed
ls /var/lib/apk/lock 2>/dev/null
sudo grep -i busybox /var/log/messages | tail
cat /proc/sys/kernel/tainted

View all alpine-3-18 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Primary reference: Alpine secdb entry — libslirp 4.6.0-r0. Manual pages useful on Alpine Linux 3.18:

apk --help
man apk
man rc-service
man rc-update
man rc-status
man iptables
man nft
man awall
man lbu

Other resources: wiki.alpinelinux.org, security.alpinelinux.org, pkgs.alpinelinux.org, and per-package notes in /usr/share/doc/libslirp/ for components implicated in libslirp — multiple vulnerabilities (8 CVEs) — patch and remediation guide.

View all Alpine Linux 3.18 tutorials on the Tutorials Hub →