CVE-2026-63827

What it actually does

This is a Linux kernel use-after-free condition in the AppArmor policy replacement path. During aa_replace_profiles(), the kernel walks the AppArmor namespace rawdata_list to deduplicate incoming policy blobs. Entries can remain temporarily on that list after their profile reference count has dropped to zero but before asynchronous cleanup removes them. The vulnerable code unconditionally increments the loaddata reference count with kref_get()-style semantics instead of using a get-unless-zero pattern, causing refcount hardening warnings and potential unsafe use of an object that is already logically dead. Because the flaw is in kernel-space security policy handling, successful exploitation could theoretically lead to local privilege escalation, kernel memory corruption, system crash, or compromise of confidentiality, integrity, and availability. The CVSS vector indicates local access and low attack complexity with required low privileges and no user interaction.

Why it matters to the business

An attacker who already has a low-privileged local foothold on a Linux system using AppArmor may be able to abuse this kernel memory-safety bug to crash the host or potentially gain elevated privileges. For organizations, the main operational risk is compromise or denial of service on Linux servers, workstations, containers, or virtualization hosts that rely on affected kernels with AppArmor enabled. The current public exploitation signal is low: EPSS is 0.00124, it is not listed in CISA KEV, no ransomware association is indicated, and no exploit maturity is reported; however, kernel privilege-escalation flaws should still be prioritized on multi-user systems, container hosts, shared build infrastructure, and internet-facing services that may be paired with another initial-access bug.

How an attack unfolds

An attacker first obtains low-privileged local execution on a Linux host where AppArmor is enabled and the running kernel contains the vulnerable AppArmor rawdata deduplication logic. The attacker then repeatedly triggers AppArmor policy load or replacement activity in a way that creates churn in profile loaddata references. Under the vulnerable race condition, a loaddata entry whose profile count has dropped to zero can remain on the namespace rawdata list until deferred cleanup runs. If the deduplication loop encounters that dying entry, it unconditionally increments a zero reference count, producing a use-after-free/refcount corruption condition in kernel context. In unweaponized reproductions this manifests as refcount_t warnings in kernel logs during AppArmor stress testing. A mature exploit would attempt to control timing and kernel heap state around the stale object to convert the bug into privilege escalation or a reliable kernel denial of service. There are no named threat actors or public exploitation reports in the provided intelligence.

How to fix it

Apply a Linux kernel update that includes the AppArmor fix introducing aa_get_profile_loaddata_not0() and using get-unless-zero semantics in the rawdata_list deduplication lookup. No exact affected product list or fixed package versions were provided, so administrators should obtain updates from their Linux distribution, appliance vendor, cloud image provider, or kernel supplier and verify that the running kernel includes the upstream AppArmor rawdata deduplication fix for this issue. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting who can load or replace AppArmor policy, disabling untrusted workloads on affected hosts, isolating multi-tenant workloads, and monitoring for AppArmor-related kernel warnings. Disabling AppArmor is generally not recommended as a mitigation because it can reduce system confinement; only consider it as a temporary vendor-approved workaround if the operational risk of the bug outweighs the loss of mandatory access controls.

How to confirm the fix worked

Confirm the system is running a patched kernel from the relevant vendor or distribution and not merely that an updated package is installed but inactive. Validate by checking the active kernel version after reboot, reviewing vendor advisories or changelogs for the AppArmor loaddata/rawdata deduplication fix, and ensuring no vulnerable kernel remains selectable in the bootloader for production use. On test systems, reproduce-oriented validation can include controlled AppArmor policy churn or stress testing while monitoring kernel logs for refcount_t warnings; absence of the specific warnings under similar load is useful but not a complete proof of remediation. Security teams should also verify that AppArmor is enabled only where intended, that policy-management privileges are limited, and that kernel hardening features such as KASAN/KCSAN are used in non-production validation where feasible.

Typical attack path

1. Gain low-privileged local code execution on an affected Linux system.
2. Confirm AppArmor is enabled and the kernel includes the vulnerable AppArmor rawdata deduplication code.
3. Generate repeated AppArmor profile load, unload, or replacement activity to create loaddata reference churn.
4. Win the race where an AppArmor loaddata entry remains on rawdata_list after its profile reference count reaches zero but before deferred cleanup removes it.
5. Cause aa_replace_profiles() to call an unconditional reference increment on the zero-count loaddata entry.
6. Trigger kernel refcount corruption, potentially resulting in a crash or, with further exploitation, elevated privileges.

How to detect it

To determine whether this flaw may have been triggered, review kernel logs and system journals for refcount hardening messages, AppArmor policy replacement errors, kernel oopses, panics, or crashes involving aa_replace_profiles(), AppArmor loaddata, rawdata_list, or refcount_t. Useful log sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd journal entries from the kernel transport, auditd records related to AppArmor policy loading, and crash dump metadata if kdump or similar tooling is enabled. Look for bursts of AppArmor profile load, unload, or replacement activity immediately before kernel warnings or crashes. Because the provided information does not include a known public exploit, named threat actors, malware artifacts, network indicators, or stable post-exploitation files, detection should focus on kernel telemetry and suspicious local activity by low-privileged users around AppArmor policy operations. Treat matching refcount_t warnings as strong evidence that the vulnerable code path was reached, but not by themselves proof of successful privilege escalation.

• refcount_t: addition on 0; use-after-free
• aa_replace_profiles()
• refcount_t: saturated
• refcount_t: underflow
• apparmor: fix use-after-free in rawdata dedup loop
• aa_get_profile_loaddata
• aa_get_profile_loaddata_not0
• rawdata_list
• do_ploaddata_rmfs
• stress-ng --apparmor 1 --klog-check --timeout 60s

What your security team should do

• Inventory Linux systems using AppArmor and identify their currently running kernel versions.
• Prioritize patching shared, multi-user, container-hosting, CI/CD, developer workstation, and internet-facing Linux systems where a local privilege-escalation primitive would have high impact.
• Apply vendor kernel updates that contain the AppArmor rawdata deduplication reference-count fix, then reboot to activate the patched kernel.
• Search historical kernel logs for AppArmor and refcount_t warning strings associated with aa_replace_profiles() to identify possible triggering or attempted exploitation.
• Restrict local access and AppArmor policy-management permissions to trusted administrators until patching is complete.
• If exploit code becomes public or the issue is added to KEV, raise priority to emergency remediation across all affected Linux assets.
• Retain kernel crash dumps, audit logs, and system journals from any host showing matching refcount warnings for forensic review.