📖 ~4 min read • Source: SUSE advisory SUSE-SU-2014:1695-1 (see also SUSE bugzilla)
Related CVEs: CVE-2014-9322 CVE-2016-10044 CVE-2018-1087 CVE-2014-0038 CVE-2014-3673 CVE-2014-3687 CVE-2014-8160 CVE-2015-1805 +12 more
Upstream summary: arch/x86/kernel/entry_64.S in the Linux kernel before 3.17.5 does not properly handle faults associated with the Stack Segment (SS) segment register, which allows local users to gain privileges by triggering an IRET instruction that leads to access to a GS Base address from the wrong space.
Table of contents
Symptom & Impact
A flaw in kernel-ec2 sits underneath every process on the host: local privilege escalation to root, container escape from an unprivileged namespace, memory corruption reachable from a crafted packet, or — in microcode, firmware and bootloader components — a weakness below SLES 12 entirely. The update only stages files on disk: kernel and initramfs in /boot, blobs under /lib/firmware. The vulnerable code stays resident until the host boots it, which is why a package-database scan calls a host patched while it still runs the flaw. kernel-ec2 is boot-time code — kernel, modules, device firmware, microcode or bootloader — not a service, so there is no unit to restart; only a reboot (or a livepatch, where one applies) loads the new build.
Environment & Reproduction
Reproduction targets SLES 12. Confirm release, registration, and installed package:
cat /etc/os-release
SUSEConnect --status-text
SUSEConnect --list-extensions 2>/dev/null | head -30
rpm -q kernel-ec2
zypper info kernel-ec2 | head -20
Exercise the workload that uses kernel-ec2 while collecting:
sudo zypper needs-rebooting; echo "exit=$?" # SLE15 SP1 / Leap 15.1+ / Tumbleweed: exit 102 (ZYPPER_EXIT_INF_REBOOT_NEEDED) = reboot required, exit 0 = not required
ls -l /run/reboot-needed /var/run/reboot-needed 2>/dev/null # marker file left by an earlier zypper transaction (path varies by release); 'zypper needs-rebooting' is the authoritative check
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 kernel-ec2
Root Cause Analysis
Root cause is documented in SUSE advisory SUSE-SU-2014:1695-1. SUSE security maintainers shipped fixes in the corresponding kernel-ec2 update for SLES 12; 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 kernel-ec2
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 SLES 12 to capture the current state of kernel-ec2:
rpm -q kernel-ec2 # installed NVR
rpm -V kernel-ec2 # verify shipped files
sudo zypper patch-check # open patches
sudo zypper lp -r SUSE-SLE-Server-12-* 2>/dev/null | head
systemctl --failed --no-pager
sudo firewall-cmd --list-all 2>/dev/null || sudo SuSEfirewall2 status 2>/dev/null
sudo aa-status # AppArmor profiles
rpm -ql kernel-ec2 | grep -E '^/(usr/lib|etc)/systemd/(system|user)/[^/]+\.(service|socket|timer|path|target|mount)$' # the units kernel-ec2 REALLY ships - NO OUTPUT means it ships no service at all, so never run systemctl on it
rpm -ql kernel-ec2 | 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
kernel-ec2and the system bus.sudo journalctl -xe -f --no-pager -
Inspect firewall posture. This release uses firewalld; SuSEfirewall2 may still be present on SLES 12 GA.
sudo firewall-cmd --list-all-zones sudo SuSEfirewall2 status 2>/dev/null # legacy, only present on early SLES 12 sudo iptables -L -n -v | head -30 -
Surface AppArmor denials and switch the profile to complain mode if needed.
sudo journalctl -k | grep -i 'apparmor="DENIED"' | tail -30 sudo aa-status -
Verify
kernel-ec2integrity and reinstall if anything is altered.sudo rpm -V kernel-ec2 sudo zypper verify sudo zypper install --force kernel-ec2 -
Correlate findings with
/var/log/zypp/history,zypper history, and SUSE advisory SUSE-SU-2014:1695-1 to pin the change that introduced the regression.
Solution – Primary Fix
Apply the corrective zypper transaction referenced by SUSE advisory SUSE-SU-2014:1695-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 kernel-ec2
# Unit name may differ from pkg name; check first:
rpm -q kernel-ec2 # 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 12):
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 kernel-ec2 # add lock zypper ll | grep kernel-ec2 # list locks sudo zypper rl kernel-ec2 # remove lock -
Install an older NVR if a regression is suspected:
zypper se -s kernel-ec2 # show all available versions sudo zypper install --oldpackage kernel-ec2-<older-NVR> -
If SuSEfirewall2 is still in use (rare on modern SLES 12), migrate to firewalld:
sudo zypper install -y firewalld sudo systemctl disable --now SuSEfirewall2 sudo systemctl enable --now firewalld -
Disable the AppArmor profile briefly to confirm policy is the cause, then re-enable:
# reproduce, capture denials in the journal: sudo journalctl -k | grep apparmor | tail -
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 kernel-ec2 # expected fixed NVR
sudo zypper patch-check # 0 critical patches outstanding
sudo firewall-cmd --list-services
sudo aa-status | head -5
sudo zypper ps -s # any services still using deleted libs
The conditions described in the advisory must no longer be reported for kernel-ec2 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-kernel-ec2' # 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 kernel-ec2-<older-NVR>
# Custom security policy cleanup:
Prevention & Hardening
Reduce the chance of this recurring on SLES 12:
-
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/12/x86_64 -
Lock sensitive packages so they cannot be auto-upgraded:
sudo zypper al kernel-ec2 -
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/12.0/x86_64 sudo zypper install -y kernel-livepatch-$(uname -r | tr - _) klp -v patches -
Keep AppArmor profiles in enforce; review
/etc/apparmor.d/after every package upgrade. -
Apply CIS SUSE Linux Enterprise Server Benchmark hardening.
Related Errors & Cross-Refs
Issues that commonly surface alongside a kernel-ec2 update: 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
View all sles-12 tutorials on the Tutorials Hub →
Browse all common problems & solutions on the Tutorials Hub.
References & Further Reading
Primary reference: SUSE advisory SUSE-SU-2014:1695-1 (see also SUSE bugzilla). Manual pages useful on SLES 12:
man zypper
man zypper.conf
man systemctl
man journalctl
man firewall-cmd
man snapper
man apparmor
man aa-status
man SUSEConnect
man klp
Other resources: SUSE Linux Enterprise Server 12 documentation, suse.com/security, SUSE security blog, and per-package notes in /usr/share/doc/packages/kernel-ec2/ for components implicated in this advisory.