In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix use-after-free in rawdata dedup loop
aareplaceprofiles() walks ns->rawdatalist to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aaloaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, doploaddatarmfs() 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.
aagetprofileloaddata() is an unconditional krefget() on pcount, so when the dedup loop hits such an entry, refcount hardening reports
refcount_t: addition on 0; use-after-free.
inside aareplaceprofiles(), 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 getunlesszero-style helper on a single counter, so the existing "if (tmp)" guard was meaningful. The split-refcount refactor introduced aagetprofileloaddata(), which has plain krefget() semantics, and the guard quietly became a no-op.
Introduce aagetprofileloaddatanot0(), matching the existing not0 convention used by aagetprofilenot0(), 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 refcountt 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 CONFIGKASAN, CONFIGKCSAN and CONFIGPROVE_LOCKING would be welcome from anyone with the cycles.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/63xxx/CVE-2026-63827.json",
"cna_assigner": "Linux"
}