π ~4 min read β’ Source: SUSE advisory SUSE-SU-2024:2002-1 (see also SUSE bugzilla)
Related CVEs: CVE-2024-35235 CVE-2023-4504 CVE-2023-34241 CVE-2023-32360 CVE-2023-32324
Upstream summary: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be
Table of contents
Symptom & Impact
On openSUSE Leap 15.5 hosts that have cups installed, administrators report behaviour consistent with SUSE advisory SUSE-SU-2024:2002-1: zypper patch-check lists open patches, services backed by cups fail or restart unexpectedly, AppArmor profile warnings appear in journalctl -k β and for security-rated advisories the host is exposed to the vulnerability set above. Impact ranges from a single service-restart loop to wider availability incidents whenever cups sits on the serving path.
Environment & Reproduction
Reproduction targets openSUSE Leap 15.5. Confirm release and installed package:
cat /etc/os-release
rpm -q cups
zypper info cups | head -20
zypper lr -E # enabled repositories
SUSEConnect --status-text 2>/dev/null || echo 'SCC not connected (optional on openSUSE Leap)'
Trigger the workflow that exposes cups β multiple vulnerabilities (5 CVEs) β patch and remediation guide while collecting:
sudo journalctl -u cups -b --no-pager | tail -200
sudo journalctl -xe --no-pager | tail -200
sudo tail -200 /var/log/zypp/history
sudo journalctl -k | grep -i apparmor | tail -100
# Bundle evidence for SUSE / community support:
sudo supportconfig -R /var/tmp -B cups
Root Cause Analysis
Root cause is documented in SUSE advisory SUSE-SU-2024:2002-1. openSUSE security maintainers shipped fixes in the corresponding cups update for openSUSE Leap 15.5; running an outdated build leaves the host exposed to the failure modes described in the advisory. Correlate zypper history with system logs:
sudo zypper history | grep cups
sudo zypper history --since='-7 days' | tail -40
sudo journalctl -k | grep -i apparmor | tail -100
cat /proc/sys/kernel/tainted # non-zero = tainted kernel / out-of-tree modules
Quick Triage
Run these on openSUSE Leap 15.5 to capture the current state of cups:
rpm -q cups # installed NVR
rpm -V cups # verify shipped files
sudo zypper patch-check # open patches
sudo zypper lp 2>/dev/null | head
systemctl --failed --no-pager
sudo firewall-cmd --list-all
sudo aa-status # AppArmor profiles
# If cups ships a systemd unit (unit name may differ from pkg name, e.g.
# bindβnamed, postgresql-serverβpostgresql, php-fpmβphp-fpm):
systemctl list-unit-files | grep -i cups | head
Step-by-Step Diagnosis
-
List failed systemd units.
systemctl --failed --no-pager -
Tail the journal for
cupsand the system bus.sudo journalctl -u cups -f --no-pager sudo journalctl -xe -f --no-pager -
Inspect firewall posture (firewalld is the default on openSUSE).
sudo firewall-cmd --list-all-zones --permanent sudo nft list ruleset 2>/dev/null | head -50 -
Surface AppArmor denials and switch the profile to complain mode if needed.
sudo journalctl -k | grep -i 'apparmor="DENIED"' | tail -30 sudo aa-status sudo aa-complain /etc/apparmor.d/usr.sbin.cups 2>/dev/null || true -
Verify
cupsintegrity and reinstall if anything is altered.sudo rpm -V cups sudo zypper verify sudo zypper install --force cups -
Inspect Snapper snapshots to know exactly which transaction introduced the regression.
sudo snapper list | tail -20 sudo snapper status <pre-id>..<post-id> -
Correlate findings with
/var/log/zypp/history,zypper history, and SUSE advisory SUSE-SU-2024:2002-1 to pin the change that introduced cups β multiple vulnerabilities (5 CVEs) β patch and remediation guide.
Solution – Primary Fix
Apply the corrective zypper transaction referenced by SUSE advisory SUSE-SU-2024:2002-1, then reload affected systemd units:
sudo zypper ref # refresh repos
sudo zypper -n patch # apply ALL open patches (recommended)
# Or target a single package:
sudo zypper -n update cups
sudo systemctl daemon-reload
# Unit name may differ from pkg name; check first:
systemctl list-unit-files | grep -i cups | head
sudo systemctl restart cups
rpm -q cups # confirm new NVR
systemctl is-active cups 2>/dev/null # confirm running (if a unit exists)
For kernel / glibc / systemd / openssl advisories a reboot is required. Snapper takes pre/post snapshots on Btrfs root automatically, giving a safety net:
sudo zypper ps -s # services using deleted libs
sudo snapper list | tail -5 # pre/post snapshots around the patch
sudo systemctl reboot # or: sudo shutdown -r now
Need help rolling this patch across an openSUSE fleet? Our IT Solutions & Services team supports openSUSE Leap and Tumbleweed estates with snapper-backed rollback workflows and salt-driven patching. Get in touch for a free consultation.
Solution – Alternative Approaches
If the primary fix is not viable, choose from these:
-
Roll back via Snapper (Btrfs snapshots are taken automatically before zypper transactions on openSUSE Leap 15.5). This is the primary safety net for openSUSE administrators:
sudo snapper list sudo snapper status <pre-id>..<post-id> # diff between two snapshot numbers sudo snapper undochange <pre-id>..<post-id> sudo snapper rollback <pre-id> # boot the host into the chosen snapshot sudo systemctl reboot -
Lock the package so zypper cannot upgrade it:
sudo zypper al cups # add lock zypper ll | grep cups # list locks sudo zypper rl cups # remove lock -
Install an older NVR if a regression is suspected:
zypper se -s cups # show all available versions sudo zypper install --oldpackage cups-<older-NVR> -
Disable the AppArmor profile briefly to confirm policy is the cause, then re-enable:
sudo aa-disable /etc/apparmor.d/usr.sbin.cups # reproduce, capture denials in the journal: sudo journalctl -k | grep apparmor | tail sudo aa-enforce /etc/apparmor.d/usr.sbin.cups -
openSUSE Leap follows the SUSE Linux Enterprise patch stream. Sync against the official update repository if a mirror has drifted:
sudo zypper mr -e repo-update # ensure update repo is enabled sudo zypper ref repo-update sudo zypper -n patch
Verification & Acceptance Criteria
All of these should pass after the fix:
rpm -q cups # expected fixed NVR
sudo zypper patch-check # 0 critical patches outstanding
systemctl is-active cups 2>/dev/null
sudo journalctl -u cups --since "5 minutes ago" --no-pager | grep -iE "error|fail" || echo OK
sudo firewall-cmd --list-services
sudo aa-status | head -5
sudo zypper ps -s # any services still using deleted libs
The original reproduction for cups β multiple vulnerabilities (5 CVEs) β patch and remediation guide must not trigger across two consecutive runs.
Rollback Plan
Capture state before any change. On openSUSE, Snapper is the canonical rollback path:
rpm -qa > /root/rpm-pre.txt
sudo zypper history list > /root/zypper-history-pre.txt
# Snapper takes pre/post snapshots automatically on Btrfs root.
sudo snapper create -d 'pre-patch-cups' # explicit named snapshot
sudo snapper list | head
To revert if the patch / roll is bad:
# Preferred on Btrfs root β boot the prior snapshot:
sudo snapper list
sudo snapper rollback <pre-id>
sudo systemctl reboot
# Or downgrade just the package:
sudo zypper install --oldpackage cups-<older-NVR>
sudo systemctl daemon-reload
sudo systemctl restart cups
# Custom AppArmor profile cleanup:
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.cups
Prevention & Hardening
Reduce the chance of this recurring on openSUSE Leap 15.5:
-
Enable automatic patch installation:
sudo zypper install -y zypper-automatic sudo systemctl enable --now zypper-automatic.timer # Or use YaST: yast2 online_update_configuration -
Subscribe to opensuse-security-announce and watch suse.com/support/update.
-
Lock sensitive packages so they cannot be auto-upgraded:
sudo zypper al cups -
Ensure Snapper is enabled on the root subvolume and pre/post hooks run for every zypper transaction. This is the cornerstone of safe openSUSE patching:
sudo snapper -c root get-config | head # Default zypper plugin: /usr/lib/zypp/plugins/commit/snapper.zypp-commit-plugin sudo snapper list | tail -10 -
Monitor file integrity with AIDE:
sudo zypper install -y aide sudo aide --init && sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db sudo aide --check -
Keep AppArmor profiles in enforce; review
/etc/apparmor.d/after every package upgrade. -
Apply CIS / openSUSE hardening guidance and use salt or ansible to enforce baseline state across the fleet.
Related Errors & Cross-Refs
Issues that commonly surface alongside cups β multiple vulnerabilities (5 CVEs) β patch and remediation guide: zypper lock contention, systemd unit ordering cycles, AppArmor denials, firewalld zone drift, and kernel taint flags. Useful triage:
sudo zypper ps -s
systemd-analyze critical-chain
sudo journalctl -k | grep apparmor | tail
sudo firewall-cmd --get-active-zones
cat /proc/sys/kernel/tainted
sudo snapper list | tail
View all opensuse-leap-15-5 tutorials on the Tutorials Hub →
Browse all common problems & solutions on the Tutorials Hub.
References & Further Reading
Primary reference: SUSE advisory SUSE-SU-2024:2002-1 (see also SUSE bugzilla). Manual pages useful on openSUSE Leap 15.5:
man zypper
man zypper.conf
man systemctl
man journalctl
man firewall-cmd
man snapper
man apparmor
man aa-status
Other resources: openSUSE documentation, suse.com/security, openSUSE security portal, and per-package notes in /usr/share/doc/packages/cups/ for components implicated in cups β multiple vulnerabilities (5 CVEs) β patch and remediation guide.
View all openSUSE Leap 15.5 tutorials on the Tutorials Hub →