AlmaLinux 8 — avahi — multiple vulnerabilities (7 CVEs) — patch and remediation guide

📖 ~4 min read  •  Source: AlmaLinux ALSA ALSA-2023:7836

Related CVEs: CVE-2021-3468 CVE-2023-38469 CVE-2023-38470 CVE-2023-38471 CVE-2023-38472 CVE-2023-38473 CVE-2023-1981

Upstream summary: Avahi is an implementation of the DNS Service Discovery and Multicast DNS specifications for Zero Configuration Networking. It facilitates service discovery on a local network. Avahi and Avahi-aware applications allow you to plug your computer into a network and, with no configuration, view other people to chat with, view printers to print with, and find shared files on other computers.

Security Fix(es):

* avahi: Local DoS by event-busy-loop from writing long lines to /run/

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

avahi runs as a long-lived process on AlmaLinux 8, started at boot and holding open sockets (visible in ss -lntp), so a flaw in it stays reachable for as long as the service is up. Exploitation usually means code execution in the daemon’s own security context, memory disclosure from a process holding credentials and cached client data, or a crash that takes the listener down. Workers started before the upgrade keep running the old binary until the unit is reloaded or restarted. avahi is a genuine long-running service, so restart steps do apply — but confirm the unit name first with systemctl list-unit-files | grep -i avahi, since it often differs from the package name (bind ships named.service).

Environment & Reproduction

Reproduction targets AlmaLinux 8. Confirm release and the installed package:

cat /etc/almalinux-release
cat /etc/os-release
rpm -q avahi
dnf info avahi | head -20

Exercise the workload that uses avahi while collecting:

sudo journalctl -u avahi-daemon -b --no-pager | tail -200
sudo journalctl -xe --no-pager | tail -200
sudo tail -200 /var/log/dnf.log
sudo tail -200 /var/log/audit/audit.log
# For an evidence bundle bundle with sosreport:
sudo sosreport --batch

Root Cause Analysis

Root cause is documented in AlmaLinux ALSA ALSA-2023:7836. AlmaLinux / Red Hat maintainers shipped fixes in the corresponding avahi update for AlmaLinux 8; running an outdated build leaves the host exposed to the failure modes described in the advisory. Correlate dnf history with system logs:

sudo dnf history | head
sudo dnf history list avahi
sudo dnf history info <id>
sudo ausearch -m AVC,USER_AVC -ts today | tail -100
cat /proc/sys/kernel/tainted   # non-zero = tainted kernel / out-of-tree modules

Quick Triage

Run these on AlmaLinux 8 to capture the current state of avahi:

rpm -q avahi                              # installed NVR
rpm -V avahi                              # verify shipped files
sudo dnf check-update --security
sudo dnf updateinfo list cves
systemctl --failed --no-pager
sudo firewall-cmd --list-all
getenforce && sestatus
# avahi runs as the "avahi-daemon" service - restart it once the upgrade is in place:
# bind→named, postgresql-server→postgresql, php-fpm→php-fpm):
systemctl list-unit-files | grep -i avahi | head

Step-by-Step Diagnosis

1. List failed systemd units.

   systemctl --failed --no-pager

2. Tail the journal for avahi and the system bus.

   sudo journalctl -u avahi-daemon -f --no-pager
   sudo journalctl -xe -f --no-pager

3. Inspect firewall posture.

   sudo firewall-cmd --list-all-zones --permanent
   sudo nft list ruleset 2>/dev/null | head -50

4. Surface SELinux denials and author a local policy module if needed.

   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 avahi integrity and reinstall if anything is altered.

   sudo rpm -V avahi
   sudo dnf reinstall avahi

6. Correlate findings with /var/log/dnf.log, dnf history, and AlmaLinux ALSA ALSA-2023:7836 to pin the change that introduced the regression.

Solution – Primary Fix

Apply the corrective dnf transaction referenced by AlmaLinux ALSA ALSA-2023:7836, then reload affected systemd units:

sudo dnf -y makecache
sudo dnf -y upgrade --security              # apply ALL security errata (recommended)
# Or target a single package:
sudo dnf -y upgrade avahi
sudo systemctl daemon-reload
# Unit name may differ from pkg name; check first:
systemctl list-unit-files | grep -i avahi | head
sudo systemctl restart avahi-daemon
rpm -q avahi                                # confirm new NVR
systemctl is-active avahi-daemon 2>/dev/null       # confirm running (if a unit exists)

For kernel / glibc / systemd / openssl advisories a reboot is required (or kpatch where licensed):

sudo needs-restarting -r                    # report whether reboot needed
sudo systemctl reboot                       # or: sudo shutdown -r now
# kpatch (Red Hat / Oracle) avoids reboot for many kernel CVEs:
sudo dnf install -y kpatch kpatch-dnf
sudo dnf kpatch auto                        # enable auto-patching
sudo kpatch list

Solution – Alternative Approaches

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

• Roll back the offending dnf transaction:

  sudo dnf history list | head
  sudo dnf history info <id>
  sudo dnf history undo <id>

• Version-lock the package so dnf cannot upgrade it:

  sudo dnf install -y python3-dnf-plugin-versionlock
  sudo dnf versionlock add avahi
  sudo dnf versionlock list
  sudo dnf versionlock delete avahi      # remove the lock

• Install an older NVR if a regression is suspected:

  dnf --showduplicates list avahi | tac | head
  sudo dnf install -y --allowerasing avahi-<older-NVR>

• Switch SELinux 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 kernel / glibc upgrades 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 systemctl reboot

• Where kpatch is licensed, apply kernel fixes without reboot:

  sudo kpatch list
  sudo kpatch load /usr/lib/modules/$(uname -r)/extra/kpatch/*.ko

Verification & Acceptance Criteria

All of these should pass after the fix:

rpm -q avahi                                            # expected fixed NVR
sudo dnf updateinfo list cves --installed               # CVEs above no longer listed
systemctl is-active avahi-daemon 2>/dev/null
sudo journalctl -u avahi-daemon --since "5 minutes ago" --no-pager | grep -iE "error|fail" || echo OK
sudo firewall-cmd --list-services
getenforce
sudo needs-restarting -r

The conditions described in the advisory must no longer be reported for avahi across two consecutive runs.

Rollback Plan

Capture state before any change:

rpm -qa > /root/rpm-pre.txt
sudo dnf history list > /root/dnf-history-pre.txt
# Optional LVM snapshot of the root LV:
sudo lvcreate -s -n preupgrade -L 4G /dev/<vg>/<lv>

To revert if the patch is bad:

sudo dnf history undo <id>
# Or downgrade just the package:
sudo dnf install -y --allowerasing avahi-<older-NVR>
sudo systemctl daemon-reload
sudo systemctl restart avahi-daemon
# Or merge the LVM snapshot and reboot:
sudo lvconvert --merge /dev/<vg>/preupgrade && sudo systemctl reboot
# Custom SELinux policy cleanup:
sudo semodule -r mylocal

Prevention & Hardening

Reduce the chance of this recurring on AlmaLinux 8:

• Enable automatic security patching:

  sudo dnf install -y dnf-automatic
  sudo sed -i 's/^upgrade_type.*/upgrade_type = security/' /etc/dnf/automatic.conf
  sudo sed -i 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
  sudo systemctl enable --now dnf-automatic.timer

• Subscribe to almalinux-announce and watch Red Hat security updates for upstream changes.

• Mirror through a local Pulp / Foreman / Spacewalk-style repo for controlled rollouts:

  sudo dnf install -y dnf-utils createrepo_c
  sudo reposync --download-metadata --downloadcomps -p /srv/mirror -- repoid=baseos
  sudo createrepo_c /srv/mirror/baseos

• Version-lock sensitive packages so they cannot be auto-upgraded:

  sudo dnf install -y python3-dnf-plugin-versionlock
  sudo dnf versionlock add avahi

• Monitor file integrity with AIDE:

  sudo dnf install -y aide
  sudo aide --init && sudo mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
  sudo aide --check

• Enable kpatch so kernel CVEs can be remediated without reboot:

  sudo dnf install -y kpatch kpatch-dnf
  sudo dnf kpatch auto
  sudo kpatch list

• Keep SELinux in enforcing mode and review custom modules in /etc/selinux/targeted/ after every package upgrade.

• Apply CIS AlmaLinux 8 Benchmark hardening and remove unused packages.

Related Errors & Cross-Refs

Issues that commonly surface alongside a avahi update: dnf lock contention, systemd unit ordering cycles, SELinux AVC bursts, firewalld zone drift, and kernel taint flags. Useful triage:

sudo dnf check
systemd-analyze critical-chain
sudo ausearch -m AVC -ts today | tail
sudo firewall-cmd --get-active-zones
cat /proc/sys/kernel/tainted
sudo needs-restarting -r

View all almalinux-8 tutorials on the Tutorials Hub →

Browse all common problems & solutions on the Tutorials Hub.

References & Further Reading

Primary reference: AlmaLinux ALSA ALSA-2023:7836. Manual pages useful on AlmaLinux 8:

man dnf
man dnf.conf
man systemctl
man journalctl
man firewall-cmd
man semanage
man audit2allow
man kpatch
man sosreport

Other resources: wiki.almalinux.org, Red Hat CVE database, AlmaLinux errata, and per-package notes in /usr/share/doc/avahi/ for components implicated in this advisory.

View all AlmaLinux 8 tutorials on the Tutorials Hub →