Qualys Reports Nine Flaws in AppArmor that Expose Millions of Linux Systems to Kernel-Level Attacks.
The Qualys Threat Research Unit (TRU) identified nine vulnerabilities in AppArmor that allow unprivileged local users to escalate privileges to root, crash systems, and break out of container isolation. AppArmor is a Mandatory Access Control (MAC) framework merged into the mainline Linux kernel in 2010. Unlike user-based permissions, it binds security policies directly to individual applications, restricting what files they can open, which network ports they can use, and which system calls they can invoke. Ubuntu, Debian, and SUSE ship it enabled by default, making it a foundational security layer for cloud instances, Kubernetes nodes, IoT devices, and enterprise servers across those distributions.
Because AppArmor underpins container isolation and least-privilege enforcement across those environments, a working bypass does not merely compromise a single process — it collapses the trust boundary for every workload depending on it.
The Confused Deputy: How the Attack Works
AppArmor exposes a set of pseudo-files under /sys/kernel/security/apparmor/ — including .load, .replace, and .remove — through which profiles are managed. These interfaces are intended to be accessible only to privileged administrators. Once the profile interface is writable by an attacker, several distinct exploitation paths open:
- Policy bypass: An attacker can load a deny-all profile for a critical service such as sshd, immediately blocking all legitimate remote access. Alternatively, removing the profile for a daemon like rsyslogd or cupsd strips away protections that previously contained those processes.
- Denial of service via stack exhaustion: AppArmor’s recursive profile-removal routine can be driven to exhaust the kernel stack — approximately 16 KB on x86-64 — by triggering removal of a deeply nested subprofile hierarchy. On systems with CONFIG_VMAP_STACK guard pages, the overflow produces a kernel panic and forces a reboot.
- Local privilege escalation to root — user space: By loading a profile that blocks Sudo’s CAP_SETUID capability and manipulating the MAIL_CONFIG environment variable, an attacker causes Sudo to invoke Postfix’s sendmail binary as root, obtaining a root shell.
- Local privilege escalation to root — kernel space: A use-after-free vulnerability in the aa_loaddata function allows an attacker to reallocate a freed memory page as a page table entry pointing to /etc/passwd, overwrite the root account’s password hash, and gain full root access via su.
- Container and namespace breakout: By loading a user-namespace profile for /usr/bin/time, an unprivileged user can create fully capable user namespaces on Ubuntu systems where such namespace creation was previously restricted — bypassing a mitigation that many organisations treat as a container security control.
- KASLR disclosure: Out-of-bounds reads in profile parsing expose kernel memory addresses, leaking the Kernel Address Space Layout Randomisation offset and enabling further exploitation steps that would otherwise require defeating that protection first.
A further structural concern compounds the risk: AppArmor’s own initialisation and service logic can unload profiles during package upgrades or service restarts, leaving processes running unconfined — with no alert to administrators — until profiles are reloaded.
Scope and Affected Systems
All Linux kernels from version 4.11 onward are affected on any distribution that integrates AppArmor. The flaw has therefore been present for approximately nine years. Affected distributions include Ubuntu, Debian, SUSE, and their derivatives.
No CVE identifiers have been assigned at the time of publication. The absence of a CVE should not be interpreted as an indication of lower severity.
Remediation and Detection
Kernel patching is the only complete remediation. Interim mitigations do not restore the security guarantees that AppArmor’s profile enforcement is intended to provide. Distribution vendors have released updated kernel packages; administrators should consult their distribution’s security advisories for the specific package versions that include the fixes.
Three operational steps are recommended in parallel with patch deployment. First, inventory all Linux endpoints running AppArmor — including cloud instances, container hosts, and Kubernetes nodes — to establish the scope of exposure before patches are deployed. Second, implement file-integrity or audit monitoring on /sys/kernel/security/apparmor/ to detect unauthorised profile modifications that may indicate active exploitation. Third, review whether AppArmor profiles are being correctly reloaded after system upgrades; processes left unconfined after a package update represent an unintended exposure even absent active exploitation.
Dr. Jakob Jung is Editor-in-Chief of Security Storage and Channel Germany. He has been working in IT journalism for more than 20 years. His career includes Computer Reseller News, Heise Resale, Informationweek, Techtarget (storage and data center) and ChannelBiz. He also freelances for numerous IT publications, including Computerwoche, Channelpartner, IT-Business, Storage-Insider and ZDnet. His main topics are channel, storage, security, data center, ERP and CRM.
Contact via Mail: jakob.jung@security-storage-und-channel-germany.de