📖 ~4 min read • Source: SUSE advisory SUSE-SU-2019:1791-1 (see also SUSE bugzilla)
Related CVEs: CVE-2019-12779 CVE-2023-39976
Upstream summary: libqb before 1.0.5 allows local users to overwrite arbitrary files via a symlink attack, because it uses predictable filenames (under /dev/shm and /tmp) without O_EXCL.
Table of contents
Symptom & Impact
Nothing executes libqb100 on its own; its code runs inside whatever links against or imports it, so the exposed surface on a SLES 16 host is the union of every process that has loaded it — web workers, cron jobs, mail handlers, backup agents. The package manager replaces the files on disk, but processes already running keep the old build mapped, and virtualenvs, vendored copies and container images each carry their own copy, so a host can report itself patched while still running vulnerable code. libqb100 is a library — code loaded by other programs rather than a daemon — so there is no unit to restart and systemctl status libqb100 will simply report no such unit; restart its consumers instead.
Environment & Reproduction
Reproduction targets SLES 16. Confirm release, registration, and installed package:
cat /etc/os-release
SUSEConnect --status-text
SUSEConnect --list-extensions 2>/dev/null | head -30
rpm -q libqb100
zypper info libqb100 | head -20
Exercise the workload that uses libqb100 while collecting:
sudo zypper ps # NATIVE SUSE TOOL, no extra package: every running process still using deleted/replaced files, plus the owning service name
sudo zypper ps -s # short table (PID, PPID, UID, login, command, service) without the per-file detail
sudo zypper ps -sss # service names ONLY, one per line - safe to pipe straight into systemctl
sudo journalctl -xe --no-pager | tail -200
sudo tail -200 /var/log/zypp/history
sudo tail -200 /var/log/audit/audit.log
# For SUSE support, bundle evidence with supportconfig:
sudo supportconfig -R /var/tmp -B libqb100
Root Cause Analysis
Root cause is documented in SUSE advisory SUSE-SU-2019:1791-1. SUSE security maintainers shipped fixes in the corresponding libqb100 update for SLES 16; 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 libqb100
sudo zypper history --since='-7 days' | tail -40
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 SLES 16 to capture the current state of libqb100:
rpm -q libqb100 # installed NVR
rpm -V libqb100 # verify shipped files
sudo zypper patch-check # open patches
sudo zypper lp -r SUSE-SLE-Server-16-* 2>/dev/null | head
systemctl --failed --no-pager
sudo firewall-cmd --list-all
getenforce # SELinux mode
rpm -ql libqb100 | grep -E '^/(usr/lib|etc)/systemd/(system|user)/[^/]+\.(service|socket|timer|path|target|mount)$' # the units libqb100 REALLY ships - NO OUTPUT means it ships no service at all, so never run systemctl on it
rpm -ql libqb100 | grep -E '^/usr/sbin/rc[^/]+$' # SUSE-only rcNAME compat symlink (it points at /usr/sbin/service, not at a unit): the NAME after 'rc' IS the service name - bind ships /usr/sbin/rcnamed, so the unit is named.service
Step-by-Step Diagnosis
-
List failed systemd units.
systemctl --failed --no-pager -
Tail the journal for
libqb100and the system bus.sudo journalctl -xe -f --no-pager -
Inspect firewall posture (firewalld is the default on SLES 15+).
sudo firewall-cmd --list-all-zones --permanent sudo nft list ruleset 2>/dev/null | head -50 -
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 -
Verify
libqb100integrity and reinstall if anything is altered.sudo rpm -V libqb100 sudo zypper verify sudo zypper install --force libqb100 -
Correlate findings with
/var/log/zypp/history,zypper history, and SUSE advisory SUSE-SU-2019:1791-1 to pin the change that introduced the regression.
Solution – Primary Fix
Apply the corrective zypper transaction referenced by SUSE advisory SUSE-SU-2019:1791-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 libqb100
sudo systemctl daemon-reload
# Unit name may differ from pkg name; check first:
sudo systemctl daemon-reload # load unit files replaced by the update; this alone restarts nothing
sudo systemctl restart UNIT1.service UNIT2.service # restart several in ONE transaction - systemd applies their own After=/Before= ordering, so low-level units (dbus, database, broker) go before their consumers
sudo systemctl restart UNIT.service # NOTE: 'systemctl reload' is NOT enough after a library patch - the process must re-exec to map the new .so
sudo systemctl reload apparmor.service # only if 'rpm -ql libqb100 | grep /etc/apparmor.d/' showed the package ships AppArmor profiles
rpm -q libqb100 # confirm new NVR
For kernel / glibc / systemd / openssl advisories a reboot is required (or SLE Live Patching where licensed):
sudo zypper ps -s # services using deleted libs
sudo systemctl reboot # or: sudo shutdown -r now
# SUSE Live Patching (kgraft / klp) avoids reboot for kernel CVEs:
sudo zypper install -y kernel-livepatch-$(uname -r | tr - _)
klp -v patches # active livepatches
Need help rolling this patch across a SUSE fleet? Our IT Solutions & Services team manages SUSE patch windows with SUSE Manager / RMT and Live Patching. Get in touch for a free consultation.
Solution – Alternative Approaches
If the primary patch is not viable, choose from these:
-
Roll back via Snapper (Btrfs snapshots taken automatically before zypper transactions on SLES 16):
sudo snapper list sudo snapper undochange <pre>..<post> # diff between two snapshot numbers sudo snapper rollback <pre> # boot the host into the chosen snapshot -
Lock the package so zypper cannot upgrade it:
sudo zypper al libqb100 # add lock zypper ll | grep libqb100 # list locks sudo zypper rl libqb100 # remove lock -
Install an older NVR if a regression is suspected:
zypper se -s libqb100 # show all available versions sudo zypper install --oldpackage libqb100-<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 -
Where SLE Live Patching is licensed, apply kernel fixes without reboot:
klp -v patches # active livepatches sudo zypper install -y kernel-livepatch-$(uname -r | tr - _)
Verification & Acceptance Criteria
All of these should pass after the fix:
rpm -q libqb100 # expected fixed NVR
sudo zypper patch-check # 0 critical patches outstanding
sudo firewall-cmd --list-services
getenforce
sudo zypper ps -s # any services still using deleted libs
The conditions described in the advisory must no longer be reported for libqb100 across two consecutive runs.
Rollback Plan
Capture state before any change:
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-libqb100' # explicit named snapshot
sudo snapper list | head
To revert if the patch is bad:
# Preferred on Btrfs root — boot the prior snapshot:
sudo snapper rollback <snapshot-id>
sudo systemctl reboot
# Or downgrade just the package:
sudo zypper install --oldpackage libqb100-<older-NVR>
sudo systemctl daemon-reload
# Custom security policy cleanup:
sudo semodule -r mylocal
Prevention & Hardening
Reduce the chance of this recurring on SLES 16:
-
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 sle-security-updates and watch suse.com/support/update.
-
Mirror through SUSE Manager or RMT (Repository Mirroring Tool) for controlled rollouts:
sudo zypper install -y rmt-server rmt-cli sudo rmt-cli sync sudo rmt-cli products enable SLES/16/x86_64 -
Lock sensitive packages so they cannot be auto-upgraded:
sudo zypper al libqb100 -
Ensure Snapper is enabled on the root subvolume and pre/post hooks run for every zypper transaction:
sudo snapper -c root get-config | head # Default zypper plugin: /usr/lib/zypp/plugins/commit/snapper.zypp-commit-plugin -
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 -
Subscribe to SUSE Live Patching so kernel CVEs can be remediated without reboot:
sudo SUSEConnect -p sle-module-live-patching/16.0/x86_64 sudo zypper install -y kernel-livepatch-$(uname -r | tr - _) klp -v patches -
SLES 16 ships with SELinux in enforcing mode by default; review and maintain custom modules in
/etc/selinux/targeted/rather than disabling enforcement. -
Apply CIS SUSE Linux Enterprise Server Benchmark hardening.
Related Errors & Cross-Refs
Issues that commonly surface alongside a libqb100 update: zypper lock contention, systemd unit ordering cycles, SELinux AVC bursts, firewalld zone drift, and kernel taint flags. Useful triage:
sudo zypper ps -s
systemd-analyze critical-chain
sudo ausearch -m AVC -ts today | tail
sudo firewall-cmd --get-active-zones
cat /proc/sys/kernel/tainted
View all sles-16 tutorials on the Tutorials Hub →
Browse all common problems & solutions on the Tutorials Hub.
References & Further Reading
Primary reference: SUSE advisory SUSE-SU-2019:1791-1 (see also SUSE bugzilla). Manual pages useful on SLES 16:
man zypper
man zypper.conf
man systemctl
man journalctl
man firewall-cmd
man snapper
man semanage
man audit2allow
man SUSEConnect
man klp
Other resources: SUSE Linux Enterprise Server 16 documentation, suse.com/security, SUSE security blog, and per-package notes in /usr/share/doc/packages/libqb100/ for components implicated in this advisory.