CrackArmor flaws in Linux AppArmor let local users gain root and weaken container isolation

Qualys has disclosed nine security flaws in Linux’s AppArmor module that can let unprivileged local users manipulate security profiles, escalate privileges to root, and weaken container isolation. The vulnerabilities, grouped under the name CrackArmor, affect Linux kernels going back to version 4.11, and Qualys says the core issue has existed since 2017.

The immediate risk is serious, but the attack model matters. These are local flaws, not remote code execution bugs. An attacker needs unprivileged local access first. From there, Qualys says the bugs can be chained to remove or replace AppArmor protections, trigger denial of service, leak kernel memory information, and in some cases achieve full root access.

AppArmor is widely used as a mandatory access control layer in Ubuntu, Debian, SUSE, and related environments, so the blast radius is broad. Qualys says more than 12.6 million enterprise Linux instances run with AppArmor enabled by default, while Canonical has confirmed that all supported Ubuntu releases are affected by the underlying confused deputy issue.

The good news is that vendors have already started shipping fixes and mitigations. Canonical says Linux kernel security updates are being released for supported Ubuntu versions, along with userspace mitigations for related issues involving sudo and su. Debian has also published Linux security updates tied to the AppArmor issues.

One detail worth highlighting is that the lack of CVE numbers does not mean the flaws are minor. Qualys says no CVEs had been assigned at publication time because the upstream kernel team usually delays CVE assignment until fixes land in stable releases. Canonical says the same and tracks the issue internally as CrackArmor.

What CrackArmor actually does

Qualys says the bugs center on a confused deputy problem in AppArmor.

In practical terms, that means an unprivileged user can abuse trusted mechanisms to load, replace, or remove AppArmor profiles through pseudo-files such as /sys/kernel/security/apparmor/.load, .replace, and .remove. That can disable protection for important services, apply deny-all policies that break access, or help open paths to privilege escalation.

Qualys also says some exploitation paths can involve privileged userspace tools such as sudo, Postfix, and su. Canonical adds an important qualifier here. On hosts that are not running container workloads, exploitation usually requires cooperation from a privileged userspace application. In Ubuntu’s write-up, su behavior can facilitate exploitation, and a separate sudo issue can also help when chained with the kernel bugs.

For containerized setups, the picture is more worrying. Canonical says that in deployments running potentially malicious attacker-controlled containers, the AppArmor kernel flaws could theoretically enable container escape scenarios without needing a cooperating privileged userspace application, although it had not been practically demonstrated at the time of writing.

Why this matters for Linux admins

This is not just a niche hardening bug.

AppArmor often acts as a trust boundary for service confinement, least-privilege enforcement, and container isolation. If a local attacker can rewrite or remove profiles, the system can lose part of the security layer that administrators expect to be there by default. Qualys says this can lead to denial of service, user-namespace bypass, local privilege escalation, and KASLR leakage through out-of-bounds reads.

Canonical’s response also tones down a few of the more alarming interpretations. It says host exploitation needs more than just AppArmor being present unless a cooperating privileged application exists. That does not make the flaws harmless, but it does mean defenders should think in terms of chained exploitation rather than a one-click root bug on every system.

CrackArmor at a glance

What admins should do now

• Apply vendor kernel updates immediately. Qualys and Canonical both say kernel patching is the main fix.
• Install related userspace updates where available, especially for sudo and util-linux on Ubuntu. Canonical says these provide important mitigations, but they do not replace the kernel fix.
• Review systems that depend heavily on AppArmor for container or service confinement. The impact rises in environments where isolation is a major trust boundary.
• Monitor for unexpected changes under /sys/kernel/security/apparmor/, which Qualys says may indicate exploitation attempts.
• Check distribution advisories rather than relying on CVE feeds alone, because official CVE identifiers were still pending at disclosure time.

FAQ