1. Summary
2. Vulnerability details
3. Impact versions
4. Recommendations
5. Mitigations
6. Detection & verification
7. References
8. Support

Qualys Threat Research Unit (TRU) disclosed a set of nine vulnerabilities in Linux AppArmor, collectively named “CrackArmor”. These flaws allow an unprivileged local user to manipulate AppArmor policy, bypass user-namespace restrictions, escalate privileges to root, and undermine container isolation. The issues have existed since Linux kernel v4.11 (2017) on distributions where AppArmor is enabled by default (notably Ubuntu, Debian, and SUSE). Immediate kernel patching is recommended; userspace mitigations (sudo/su hardening) are also available from some vendors.

CVE/CVSS3: As of March 16, 2026, no CVE identifiers have been assigned to the CrackArmor issues. CVSS scoring is pending vendor assignments; however, it seems likely the severity will be at least High if not Critical.

Impact: Local privilege escalation (LPE) to root; denial of service via kernel stack exhaustion; KASLR information disclosure via out-of-bounds reads; possible container isolation bypass; policy manipulation (loading/removing/replacing profiles).

CrackArmor centers on a confused-deputy design issue in AppArmor policy management interfaces. An unprivileged user can coerce a privileged program (e.g., su, sudo/Postfix) into writing attacker-controlled data to AppArmor pseudo-files under /sys/kernel/security/apparmor/ (.load, .replace, .remove). When combined with additional flaws in AppArmor profile parsing and concurrency, this enables multiple exploitation paths:

• Policy manipulation: remove protections for key daemons (e.g., rsyslogd, cupsd) or load a deny-all profile for sshd to block access.
• User-space LPE: create a fail-open condition in sudo (mail notification path) and leverage Postfix to execute commands as root.
• Kernel-space LPE: exploit a use-after-free during profile load/replace to overwrite sensitive data (e.g., in-memory /etc/passwd page) and gain root.
• Denial of Service: trigger uncontrolled recursion during profile removal, exhausting the kernel stack and crashing the system.
• Information disclosure: out-of-bounds reads leak kernel memory, potentially revealing KASLR-randomized pointers.
• Double-free and other logic errors reachable via malicious profiles, enabling further privilege escalation on some distributions.

All Linux kernels since v4.11 are affected on systems where AppArmor is enabled. Distributions include Ubuntu, Debian, SUSE and derivatives. Vendor advisories provide kernel build numbers that include fixes and, where applicable, userspace mitigations (sudo/util-linux).

• Ubuntu: https://ubuntu.com/security/vulnerabilities/crackarmor
• Debian: https://lists.debian.org/debian-security-announce/2026/msg00071.html
• SUSE: Multiple sources reported a patch had been released, but there is no direct statement of a fix; however, this should be accurate:

  SUSE Family	Kernel Series	CrackArmor Patch Status
  SLES / SLE 15 SP1–SP5	5.14 / 5.15 LTS	✔ Patched (5.15.x LTS branch) [upwind.io]
  SLES / SLE 15 SP6	6.1 LTS	✔ Patched (6.1.x LTS branch) [upwind.io]
  openSUSE Leap 15.x	5.14 / 5.15	✔ Patched
  openSUSE Tumbleweed	6.7–6.8 kernels	✔ Patched (6.8.x series) [upwind.io]

• Raspbian: No sign of an update yet; however, AppArmor is not enabled by default. https://pip.raspberrypi.com/categories/1260-security

Not impacted versions:

• RHEL / CentOS / Rocky / AlmaLinux: Uses SELinux, not impacted
• MacOS: Does not use AppArmor uses its own proprietary technologies to achieve similar security goals
• Android: Uses SELinux, not impacted
• BSD/OpenBSD: Does not use AppArmor, primarily uses application-level sandboxing

Patch immediately: apply vendor kernel updates that address the AppArmor vulnerabilities; reboot to load the new kernel.

• Apply userspace mitigations from vendors: update sudo and util-linux (su) where fixes are available to reduce exploitability on hosts.
• Harden containers/Kubernetes: ensure nodes are patched; restrict ability for untrusted workloads to run with broad capabilities; prefer minimal images.
• Monitor for policy tampering: watch for unexpected writes to /sys/kernel/security/apparmor/.load, .replace, and .remove and for sudden changes in confinement state.
• Audit critical services: verify AppArmor profiles for sshd, rsyslogd, cupsd, and other key daemons remain present and enforced.
• Limit local exposure: restrict interactive shell access on servers; review sudoers policy; consider disabling unprivileged user namespaces where feasible.

When updating is not feasible, some userspace mitigations are available but will not provide the same level of protection as patching.

• Update util-linux and sudo
  • sudo apt update
  • sudo apt install sudo util-linux

A system may be affected if it is running a vulnerable kernel version and AppArmor is enabled. Administrators can quickly check this using:

uname -r

to view the running kernel version.
To verify that AppArmor is active:

apparmor_status

or

cat /sys/module/apparmor/parameters/enabled

If the output returns Y, AppArmor is enabled.

Some exploitation paths rely on chaining AppArmor policy manipulation through privileged helper programs, particularly su.

Investigate unexpected usage patterns such as:
su -P
su –pty
su invoked from untrusted processes
su combined with output redirection into AppArmor policy interfaces
These patterns may indicate attempts to indirectly trigger privileged operations.

Unexpected sudo failures related to privilege transitions may also be relevant, including errors such as:
 
setresuid(…): Operation not permitted
 
unable to open /etc/sudoers: Operation not permitted
 
error initializing audit plugin sudoers_audit
 
These may indicate attempts to create fail-open conditions through policy manipulation.

1. Qualys TRU Blog: CrackArmor – Critical AppArmor Flaws Enable Local Privilege Escalation to Root
2. Qualys Security Advisory (full technical details)
3. Ubuntu Security – CrackArmor Vulnerability Knowledge Base (status, mitigations)

As always, please let us know if you have any questions or concerns or see unusual activity on your systems that you believe might be associated with this or any other vulnerability. Please send these communications to security.response@utoronto.ca.