π ~4 min read β’ Source: SUSE security advisory (see also SUSE bugzilla)
Related CVEs: CVE-2009-1962 CVE-2009-4227
Upstream summary: Xfig, possibly 3.2.5, allows local users to read and write arbitrary files via a symlink attack on the (1) xfig-eps[PID], (2) xfig-pic[PID].pix, (3) xfig-pic[PID].err, (4) xfig-pcx[PID].pix, (5) xfig-xfigrc[PID], (6) xfig[PID], (7) xfig-print[PID], (8) xfig-export[PID].err, (9) xfig-batch[PID], (10) xfig-exp[PID], or (11) xfig-spell.[PID] temporary files, where [PID] is a process ID.
Table of contents
Symptom & Impact
On openSUSE Tumbleweed hosts that have xfig installed, administrators report behaviour consistent with SUSE security advisory: zypper dup --dry-run shows pending rolling updates, services backed by xfig 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 xfig sits on the serving path.
Environment & Reproduction
Reproduction targets openSUSE Tumbleweed. Confirm release and installed package:
cat /etc/os-release
rpm -q xfig
zypper info xfig | head -20
zypper lr -E # enabled repositories
Trigger the workflow that exposes xfig β multiple vulnerabilities (2 CVEs) β patch and remediation guide while collecting:
sudo journalctl -u xfig -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 xfig
Root Cause Analysis
Root cause is documented in SUSE security advisory. openSUSE security maintainers shipped fixes in the corresponding xfig update for openSUSE Tumbleweed; 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 xfig
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
snapper list | tail -20 # snapshots taken around each zypper transaction
Quick Triage
Run these on openSUSE Tumbleweed to capture the current state of xfig:
rpm -q xfig # installed NVR
rpm -V xfig # verify shipped files
sudo zypper ref # refresh repos
sudo zypper dup --dry-run # pending rolling updates
systemctl --failed --no-pager
sudo firewall-cmd --list-all
sudo aa-status # AppArmor profiles
# If xfig 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 xfig | head
Step-by-Step Diagnosis
-
List failed systemd units.
systemctl --failed --no-pager -
Tail the journal for
xfigand the system bus.sudo journalctl -u xfig -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.xfig 2>/dev/null || true -
Verify
xfigintegrity and reinstall if anything is altered.sudo rpm -V xfig sudo zypper verify sudo zypper install --force xfig -
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 security advisory to pin the change that introduced xfig β multiple vulnerabilities (2 CVEs) β patch and remediation guide.
Solution – Primary Fix
Apply the corrective zypper transaction referenced by SUSE security advisory, then reload affected systemd units:
sudo zypper ref # refresh repos
# Tumbleweed is a rolling release β use 'dup', not 'patch':
sudo zypper dup --no-allow-vendor-change # rolling distribution upgrade
# To target only the affected package while still on rolling:
sudo zypper dup --no-allow-vendor-change xfig
sudo systemctl daemon-reload
# Unit name may differ from pkg name; check first:
systemctl list-unit-files | grep -i xfig | head
sudo systemctl restart xfig
rpm -q xfig # confirm new NVR
systemctl is-active xfig 2>/dev/null # confirm running (if a unit exists)
For kernel / glibc / systemd / openssl rolls a reboot is required. Tumbleweed does not ship Live Patching, so plan a maintenance window or use Snapper to roll back if a regression appears:
sudo zypper ps -s # services using deleted libs
sudo snapper list | tail -5 # confirm pre/post snapshots exist
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 Tumbleweed). 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 xfig # add lock zypper ll | grep xfig # list locks sudo zypper rl xfig # remove lock -
Install an older NVR if a regression is suspected:
zypper se -s xfig # show all available versions sudo zypper install --oldpackage xfig-<older-NVR> -
Disable the AppArmor profile briefly to confirm policy is the cause, then re-enable:
sudo aa-disable /etc/apparmor.d/usr.sbin.xfig # reproduce, capture denials in the journal: sudo journalctl -k | grep apparmor | tail sudo aa-enforce /etc/apparmor.d/usr.sbin.xfig -
Pin Tumbleweed to a known-good snapshot from the openSUSE history server while you investigate. This keeps the rolling release reproducible across a fleet:
# Edit /etc/zypp/repos.d/repo-oss.repo and point baseurl at # http://download.opensuse.org/history/<YYYYMMDD>/tumbleweed/repo/oss/ sudo zypper ref sudo zypper dup --no-allow-vendor-change
Verification & Acceptance Criteria
All of these should pass after the fix:
rpm -q xfig # expected fixed NVR
sudo zypper dup --dry-run # no pending rolls expected
systemctl is-active xfig 2>/dev/null
sudo journalctl -u xfig --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 xfig β multiple vulnerabilities (2 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-xfig' # 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 xfig-<older-NVR>
sudo systemctl daemon-reload
sudo systemctl restart xfig
# Custom AppArmor profile cleanup:
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.xfig
Prevention & Hardening
Reduce the chance of this recurring on openSUSE Tumbleweed:
-
Run rolling upgrades on a schedule β Tumbleweed receives a snapshot most weekdays. Stagger across the fleet so any regression is caught early:
sudo zypper ref sudo zypper dup --no-allow-vendor-change # Optional: drive from salt/ansible with a maintenance window per host group. -
Subscribe to opensuse-security-announce and watch suse.com/support/update.
-
Lock sensitive packages so they cannot be auto-upgraded:
sudo zypper al xfig -
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 xfig β multiple vulnerabilities (2 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-tumbleweed tutorials on the Tutorials Hub →
Browse all common problems & solutions on the Tutorials Hub.
References & Further Reading
Primary reference: SUSE security advisory (see also SUSE bugzilla). Manual pages useful on openSUSE Tumbleweed:
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/xfig/ for components implicated in xfig β multiple vulnerabilities (2 CVEs) β patch and remediation guide.
View all openSUSE Tumbleweed tutorials on the Tutorials Hub →