CVE-2026-47326

What it actually does

This is a local denial-of-service vulnerability in Ubuntu Linux kernels carrying Ubuntu SAUCE AppArmor patches. An unprivileged local user can trigger a memory leak by causing AppArmor notification handling to process large responses. Repeated triggering can steadily consume kernel/system memory until the host experiences memory pressure, out-of-memory killing, degraded service, or a crash/reboot. The flaw does not directly provide confidentiality or integrity impact and does not directly grant code execution or privilege escalation, but availability impact is high because it can exhaust system resources from a low-privileged account.

Why it matters to the business

A user or compromised low-privileged workload on an affected Ubuntu system could make the system unstable or unavailable, disrupting hosted applications, build systems, shared servers, containers, developer workstations, or other services depending on that host. Because exploitation requires local access, the greatest business risk is from multi-user systems, shared compute, container hosts, jump boxes, CI/CD runners, and systems where attackers may already have a foothold. It is not listed in CISA KEV, is not currently associated with ransomware use, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, the operational impact can still be significant where untrusted local users or workloads are present.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user on an affected Ubuntu Linux system. They then interact with behavior governed by AppArmor notification handling and cause the kernel to process unusually large AppArmor notification responses. Due to the memory leak in the Ubuntu-specific AppArmor patch path, memory allocated during this handling is not properly released. By repeating the trigger, the attacker causes unreclaimed memory to accumulate. As free memory drops, the host may begin swapping, slow dramatically, invoke the out-of-memory killer, terminate unrelated processes, fail service health checks, or crash/reboot. The attacker does not need elevated privileges, user interaction, or network reachability to the vulnerable code path, but they do need local execution capability.

How to fix it

Apply Canonical/Ubuntu kernel updates that include the fix for this AppArmor notification memory leak as soon as they are available for the affected release and kernel stream. No fixed package versions were provided in the input, so use the Ubuntu Security Notices, kernel changelogs, and package manager metadata as the source of truth for exact fixed kernel package versions. After installing the updated kernel, reboot systems so the patched kernel is active. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads, isolating multi-tenant workloads, enforcing resource limits with cgroups/systemd where applicable, monitoring memory pressure, and disabling or avoiding AppArmor notification features only if operationally acceptable and validated by the system owner. Do not rely on process restarts alone; the vulnerable code is in kernel/AppArmor handling and requires a patched active kernel to fully remediate.

How to confirm the fix worked

Confirm whether systems are exposed by checking the running Ubuntu kernel version and comparing it with Canonical’s fixed kernel packages for the relevant release. Verify the active kernel after remediation with commands such as `uname -a`, `uname -r`, and package queries such as `dpkg -l 'linux-image*' 'linux-modules*' | grep '^ii'`. Ensure the system has been rebooted into the fixed kernel; installing the package without rebooting leaves the vulnerable kernel active. Confirm AppArmor status with `aa-status` or `systemctl status apparmor` where applicable. Validate mitigation by monitoring memory usage under normal workload and confirming that prior symptoms such as repeated OOM kills, unexplained kernel memory growth, or host instability no longer occur. If using vulnerability scanners or compliance tooling, ensure signatures account for the active running kernel, not only installed packages.

Typical attack path

1. Gain local code execution as an unprivileged user, such as through a shell account, compromised application user, container escape-adjacent workload access, CI job, or other low-privileged foothold.
2. Identify that the host is running an affected Ubuntu kernel series with AppArmor enabled and Ubuntu SAUCE AppArmor notification patches present.
3. Generate AppArmor notification activity that results in large responses being handled by the vulnerable code path.
4. Repeat the trigger to leak kernel/system memory over time.
5. Drive the system into memory pressure, causing latency, process failures, out-of-memory kills, service outages, or a host crash/reboot.
6. Optionally stop activity after disruption to make the event appear as an intermittent resource exhaustion incident rather than an intentional local denial-of-service attack.

How to detect it

Look for evidence of resource exhaustion rather than a single definitive exploit signature. Useful sources include kernel logs, systemd journal, audit logs, AppArmor logs, EDR process telemetry, resource monitoring, and host reboot history. Search `/var/log/kern.log`, `/var/log/syslog`, `/var/log/audit/audit.log`, and `journalctl -k` for bursts of AppArmor/audit activity followed by rising memory pressure, OOM killer activity, killed processes, service failures, or unexpected reboots. Correlate timestamps with local user sessions, cron jobs, CI jobs, containers, or recently executed processes from low-privileged accounts. Investigate repeated AppArmor notification or denial events, unusually large or frequent AppArmor-related audit records, abnormal growth in memory consumption without a corresponding user-space process, and OOM kills affecting unrelated services. Because the issue is a kernel memory leak, artifacts may be indirect; absence of a unique IOC does not prove absence of exploitation.

• Out of memory: Killed process
• invoked oom-killer
• oom-kill:
• Memory cgroup out of memory
• oom_reaper
• kernel: apparmor
• apparmor="DENIED"
• apparmor="ALLOWED"
• audit: type=1400
• audit: type=1400 apparmor=

What your security team should do

• Prioritize patching shared, multi-user, CI/CD, container-hosting, bastion, developer, and other systems where untrusted or semi-trusted local code can run.
• Track Canonical Ubuntu Security Notices and kernel package advisories for exact fixed versions, then deploy the fixed kernel and reboot affected systems.
• Inventory affected Ubuntu Linux hosts by running kernel version and exposure profile; do not treat systems as remediated until the patched kernel is actively booted.
• Increase monitoring for memory pressure, OOM killer events, abnormal AppArmor/audit activity, and unexplained host reboots on affected systems until remediation is complete.
• Restrict local access and untrusted workload execution on affected hosts, especially where multiple users or tenants share the same kernel.
• Apply resource controls where practical, such as cgroup memory limits, systemd service limits, job timeouts, and automated recovery for critical services, recognizing these are mitigations rather than a complete fix.
• Review recent outages or instability on affected Ubuntu systems for signs of repeated OOM events or AppArmor-related activity that could indicate prior exploitation.
• Because the vulnerability is not KEV-listed, has no known mature public exploit in the provided data, and has very low EPSS, prioritize based on local-user exposure and business criticality rather than internet exposure alone.