CVE-2026-45884

What it actually does

This is a local availability flaw in the Linux kernel AppArmor subsystem. The vulnerable code path in aa_get_buffer() can decrement an unsigned per-CPU buffer-cache hold counter below zero when hold reaches 0 while buffers remain counted. That underflow wraps the counter to a very large value, preventing aa_put_buffer() from returning buffers to the global list for an extended period. As a result, other CPUs can be starved of reusable AppArmor path buffers and the kernel may repeatedly allocate large buffers with kmalloc(aa_g_path_max), creating memory pressure and potentially causing degraded performance, allocation failures, or denial of service. The issue requires local privileges and does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems that run affected Linux kernels with AppArmor enabled may be susceptible to local denial-of-service conditions caused by an untrusted user, compromised local account, containerized workload, or multi-user workload. Successful exploitation can degrade host performance, increase memory pressure, disrupt applications, or make a server unstable or unavailable. The issue is not currently listed in CISA KEV, has no known ransomware association, and has very low EPSS at the time of assessment, so broad internet-scale exploitation is unlikely; however, it remains relevant for shared Linux hosts, container platforms, developer workstations, bastion hosts, and systems where untrusted users can execute local code.

How an attack unfolds

An attacker first needs the ability to execute code or commands locally on a system running an affected Linux kernel with AppArmor active. The attacker then generates repeated filesystem/pathname operations that cause AppArmor to request and release path buffers through aa_get_buffer() and aa_put_buffer(). Under the vulnerable accounting condition, a per-CPU hold counter can underflow from 0 to UINT_MAX. Once this happens, the buffer cache appears to have a long-lived nonzero hold state, so returned buffers are not moved back to the global list as expected. Other CPUs may then lack reusable buffers and repeatedly allocate new AppArmor path buffers from kernel memory. By sustaining this activity, the attacker can amplify kernel memory pressure and cause performance degradation, allocation failures, or service disruption. There is no indication from the provided data of public exploit maturity or active exploitation by named threat actors.

How to fix it

Upgrade to a Linux kernel build that includes the upstream AppArmor fix that guards the aa_get_buffer() decrement so the per-CPU hold counter cannot underflow. Because no exact fixed package versions were provided, use the relevant Linux distribution security advisory, vendor kernel changelog, or upstream stable kernel release notes to identify the corrected kernel for each supported distribution. After installing the fixed kernel, reboot systems so the patched kernel is running. Where immediate patching is not possible, reduce exposure by limiting local shell access, constraining untrusted workloads with cgroups and memory limits, reducing multi-tenant use on affected hosts, monitoring for memory pressure, and prioritizing patching for systems that allow untrusted local code execution. Disabling AppArmor may avoid this specific code path but weakens system confinement and should only be considered as a temporary, risk-accepted workaround if advised by the operating system vendor.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking uname -a or the distribution-specific package inventory after reboot. Validate that the applied kernel contains the AppArmor fix for aa_get_buffer() that prevents cache->hold from being decremented when it is already zero. On source-based or custom kernels, review the AppArmor buffer-cache code to ensure the decrement is guarded and cannot underflow. Operationally, verify that memory pressure, AppArmor-related allocation failures, and kernel allocation warnings do not recur under representative workload. For fleets, compare kernel package versions against vendor advisories and ensure all affected hosts have rebooted into the fixed kernel image.

Typical attack path

1. Gain local code execution through a legitimate account, compromised account, container workload, or other local execution path.
2. Confirm the target is running an affected Linux kernel and that AppArmor mediation is enabled.
3. Trigger high volumes of operations that exercise AppArmor pathname mediation and buffer allocation paths.
4. Cause aa_get_buffer() to decrement the per-CPU hold counter when it should not, resulting in unsigned counter underflow.
5. Sustain activity so AppArmor buffers are not returned to the global list and other CPUs perform repeated kmalloc-based allocations.
6. Induce memory pressure, allocation failures, degraded system performance, or host/service unavailability.

How to detect it

There is no single definitive artifact that proves exploitation of this flaw, and normal AppArmor activity can produce similar logs. To investigate possible prior exploitation, review kernel logs, system journals, audit logs, and endpoint telemetry for the period before patching. Focus on signs of unusual AppArmor-related activity followed by memory pressure or allocation failures, including repeated AppArmor audit records, kernel allocation warnings, OOM-killer events, soft lockups, or service crashes. Useful sources include journalctl -k, /var/log/kern.log, /var/log/syslog, /var/log/messages, auditd logs such as /var/log/audit/audit.log, EDR process telemetry, container runtime logs, and workload scheduler events. Correlate high-volume local filesystem or pathname operations from the same user, process, container, or service with kernel memory exhaustion. Stack traces or warnings that include AppArmor buffer functions such as aa_get_buffer or aa_put_buffer are especially relevant, but their absence does not rule out exploitation.

• aa_get_buffer
• aa_put_buffer
• apparmor
• audit: type=1400
• apparmor="DENIED"
• apparmor="ALLOWED"
• page allocation failure
• Out of memory
• oom-killer
• Memory cgroup out of memory
• kmalloc
• aa_g_path_max
• soft lockup
• kernel BUG
• WARNING: CPU

What your security team should do

• Prioritize patching Linux systems that allow local users, CI/CD jobs, containers, shared hosting workloads, or other untrusted code execution.
• Track distribution-specific kernel advisories and deploy the first available fixed kernel that includes the AppArmor aa_get_buffer() underflow fix.
• Reboot after patching and verify the running kernel version across the fleet.
• Use endpoint, audit, and kernel telemetry to look for unusual local activity correlated with AppArmor mediation, memory pressure, allocation failures, or OOM events.
• Apply cgroup, container, and user resource limits on systems that cannot be patched immediately.
• Limit interactive shell access and remove unnecessary local accounts from affected hosts.
• Treat repeated unexplained memory exhaustion on AppArmor-enabled affected kernels as potentially suspicious, especially on shared or multi-tenant systems.
• Do not disable AppArmor as a routine fix; use vendor-patched kernels rather than removing a security control.