CVE-2026-47332

What it actually does

This is a local information disclosure vulnerability in Ubuntu-specific AppArmor kernel patches affecting Linux kernel lines 6.8, 6.17, and 7.0. The notification handling code incorrectly validates the size of an internal structure, allowing an unprivileged local user to trigger an out-of-bounds read. Successful exploitation can disclose data from adjacent kernel slab objects, potentially exposing kernel pointers, security-relevant metadata, or other sensitive in-memory values. The flaw does not directly provide code execution, integrity modification, or denial of service, but leaked kernel memory may help bypass protections such as KASLR or support chaining with a separate privilege-escalation vulnerability.

Why it matters to the business

The primary risk is that a user or compromised low-privilege account on an affected Ubuntu system could obtain sensitive kernel memory contents. On shared systems, developer workstations, build hosts, bastion hosts, or multi-user servers, this may increase the chance that an attacker can turn initial local access into deeper compromise by using leaked data to defeat kernel hardening. The CVSS score is medium and EPSS is currently very low, with no known CISA KEV listing or reported ransomware use, so urgency is lower than for remotely exploitable vulnerabilities, but systems that allow interactive shell access or run untrusted local workloads should be prioritized.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user on an affected Ubuntu kernel. They then exercise the AppArmor notification interface in a way that reaches the vulnerable notification handling path with a structure size that is accepted incorrectly. Because the kernel validates the size incorrectly, the code reads beyond the intended structure boundary and returns or exposes bytes from adjacent slab allocations. The attacker can repeat the operation to collect leaked memory and analyze it for useful values such as kernel addresses, object contents, or security metadata. The disclosure alone does not grant administrative privileges, but it can materially improve reliability of a second-stage exploit that requires knowledge of kernel memory layout or object state.

How to fix it

Apply the relevant Ubuntu kernel security update from Canonical as soon as it is available for the affected release and kernel line. Because no fixed package versions were provided in the input, use Canonical Ubuntu Security Notices, package changelogs, and distribution advisories to identify the first kernel package that includes the fix for CVE-2026-47332. After installing the updated kernel, reboot the system so the patched kernel is actually running. Where immediate patching is not possible, reduce exposure by limiting interactive shell access, removing unnecessary local users, restricting untrusted workloads, using least-privilege service accounts, and monitoring for unusual AppArmor notification interface activity. Do not rely on disabling AppArmor as a primary mitigation unless directed by the vendor, because doing so may remove important confinement protections and increase overall risk.

How to confirm the fix worked

Confirm remediation by verifying both the installed kernel package and the running kernel after reboot. Check the running kernel with `uname -r` and compare it against Canonical’s fixed kernel packages for the relevant Ubuntu release. Review `apt changelog` or Ubuntu Security Notices for the kernel package to confirm the CVE is listed as fixed. Ensure there are no pending kernel upgrades and that the system has rebooted into the patched kernel rather than continuing to run an older vulnerable kernel. Exposure validation should focus on Ubuntu systems running affected 6.8, 6.17, or 7.0 kernel lines with AppArmor enabled; systems not using the affected Ubuntu AppArmor patch set are less likely to be impacted by this specific issue.

Typical attack path

1. Obtain local unprivileged access to an affected Ubuntu Linux system, such as through a normal user account, compromised service account, container escape prerequisite, or malicious local workload.
2. Confirm the system is running an affected Ubuntu kernel branch with AppArmor enabled and the vulnerable notification handling code reachable.
3. Run a local program that interacts with AppArmor notification handling using malformed or boundary-case structure sizes.
4. Trigger the out-of-bounds read and collect disclosed bytes from adjacent kernel slab objects.
5. Repeat the leak to recover useful kernel memory artifacts such as addresses or metadata.
6. Optionally combine the information leak with a separate local privilege-escalation vulnerability to improve exploit reliability or bypass kernel hardening.

How to detect it

There is unlikely to be a reliable, vendor-neutral log entry that proves this vulnerability was exploited, because the core behavior is a local kernel out-of-bounds read and may not generate audit records. Detection should focus on evidence of local exploit preparation and unusual interaction with AppArmor notification interfaces. Review authentication logs for unexpected local or SSH sessions, sudo attempts, new user creation, and activity by low-privilege accounts on affected systems. Review auditd, syslog, journald, and EDR telemetry for processes accessing AppArmor securityfs paths under `/sys/kernel/security/apparmor`, repeated AppArmor notification activity, execution of unknown binaries from writable directories, compiler usage by non-developer accounts, and suspicious crashes or kernel warnings around AppArmor. If auditd is deployed, consider rules that watch AppArmor securityfs paths and execution from temporary directories. Because exploitation may be quiet and only disclose memory to the invoking process, absence of logs should not be treated as proof of non-exploitation.

• /sys/kernel/security/apparmor
• /sys/kernel/security/apparmor/.notify
• apparmor_notify
• apparmor="DENIED"
• apparmor="ALLOWED"
• audit: type=1400
• kernel: audit: type=1400
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Inventory Ubuntu systems running Linux kernel 6.8, 6.17, or 7.0 and prioritize those with multiple users, SSH access, developer workloads, CI/CD workloads, or untrusted local code execution.
• Track Canonical security advisories for the fixed kernel packages and patch affected systems during the next appropriate maintenance window, with faster handling for shared or high-value systems.
• Reboot after kernel updates and verify the running kernel is the patched version, not merely that the package is installed.
• Restrict local access where feasible, including disabling unused accounts, enforcing MFA for remote access paths, and limiting who can execute code on affected hosts.
• Monitor for suspicious local probing of AppArmor securityfs paths and unusual AppArmor notification tooling, while recognizing that successful exploitation may leave little direct forensic evidence.
• Treat any confirmed memory disclosure on a sensitive host as a potential enabler for further local privilege escalation and review for follow-on suspicious activity.