# CVE-2026-63827: apparmor: fix use-after-free in rawdata dedup loop

> A use-after-free in the Linux kernel AppArmor module allows attackers to trigger refcount warnings and potential crashes or code execution during profile replacement.

- **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 19 Jul 2026
- **Updated:** 17 Aug 2026
- **Also known as:** BELL-CVE-2026-63827, DEBIAN-CVE-2026-63827, GHSA-gpp3-g5wp-8xhw, ROOT-OS-DEBIAN-11-CVE-2026-63827, ROOT-OS-UBUNTU-2204-CVE-2026-63827, UBUNTU-CVE-2026-63827

## What is CVE-2026-63827?

CVE-2026-63827 is a high-severity use after free vulnerability in Linux, published on 19 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

In the Linux kernel, the following vulnerability has been resolved:

apparmor: fix use-after-free in rawdata dedup loop

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.

## Which versions are affected by CVE-2026-63827?


## How do I fix CVE-2026-63827?

Apply the vendor's patch.

## Is CVE-2026-63827 being exploited?

There is no known exploitation of CVE-2026-63827 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-63827 and fix it if it is affected.

What it is: CVE-2026-63827 is a high-severity use after free vulnerability in Linux, published on 19 Jul 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-63827 in the wild and no public exploit code.

Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-63827/ (Markdown: https://insights.sbomify.com/CVE-2026-63827/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-63827
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-63827
- OSV: https://osv.dev/vulnerability/CVE-2026-63827

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-63827/
Summaries are generated and may contain mistakes; the official description above is the record.