Look up another CVE · open CVE-2026-63827 in the interactive tracker
CVE-2026-63827
apparmor: fix use-after-free in rawdata dedup loop
Published 2026-07-19 (3 months ago) by the Linux kernel CNA. Subsystem security/apparmor. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-63827 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixed | 6.1.177-1 | Update the kernel and reboot. Fixed in 6.1.177-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.95-1 | Update the kernel and reboot. Fixed in 6.12.95-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.3-1 | Update the kernel and reboot. Fixed in 7.1.3-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips "saturated" and "underflow" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 ("apparmor: fix race on rawdata dereference") the dedup path used a get_unless_zero-style helper on a single counter, so the existing "if (tmp)" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
security/apparmor/include/policy_unpack.h
security/apparmor/policy.c
- What this is
- APPARMOR SECURITY MODULEMAINTAINERS section matched on security/apparmor/ · apparmor@lists.ubuntu.com · Supported
Check it on the machine
grep -w CONFIG_SECURITY_APPARMOR /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switch
- CONFIG_SECURITY_APPARMOR
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-07-19 (3 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.9% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- security/apparmor
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10.253 | 5.10.261 | 643221da57db |
| 5.15.203 | 5.15.212 | b17f0c59cc15 |
| 6.1.169 | 6.1.177 | a7a2890028f1 |
| 6.6.130 | 6.6.144 | 15fd83a1e42e |
| 6.12.77 | 6.12.95 | ce261a20b41d |
| 6.18.18 | 6.18.38 | c3ca2631073b |
| 7.0 | 7.1.3 | 5e34fa9f6f7c |
| 7.0 | 7.2 | 6f060496d03e |
| 6.19.8 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4717-1 | 2026-08-05 | bullseye 5.10.262-1 | tracker |
| DLA-4700-1 | 2026-07-26 | bullseye 6.1.177-1~deb11u1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached only via local write() to AppArmor policy management interfaces (.load/.replace) under securityfs/apparmorfs, not through any network-facing protocol.
- AC:LAttack complexity, low
- An attacker with policy-admin capability can reliably win the race by concurrently loading/replacing and removing profiles with identical rawdata blobs, as demonstrated by stress-ng reproducing refcount UAF warnings within seconds.
- PR:LPrivileges required, low
- Triggering aa_replace_profiles() requires CAP_MAC_ADMIN plus policy-view rights; on typical AppArmor deployments (e.g. Ubuntu) namespace-root in an unprivileged user namespace can obtain CAP_MAC_ADMIN via unprivileged_userns_apparmor_policy without init-namespace root.
- UI:NUser interaction, none
- Exploitation is driven entirely by the attacker's own policy load/replace/remove operations and does not require any action from another user or administrator.
- S:UScope, unchanged
- Impact is kernel memory corruption and potential local privilege escalation within the same kernel security boundary, not a cross-VM or cross-security-authority escape.
- C:HConfidentiality impact, high
- The vulnerability is a use-after-free on aa_loaddata profile refcounts; refcount hardening reports "addition on 0; use-after-free" and poisons the counter, creating a path to arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- UAF and refcount saturation/underflow on aa_loaddata enable heap corruption primitives that can be leveraged for arbitrary kernel writes and local privilege escalation.
- A:HAvailability impact, high
- The bug reliably triggers refcount_t UAF warnings and corrupts subsequent refcount operations on the same loaddata, causing kernel instability and potential crash/panic under concurrent policy management.