CVE-2026-45893

What it actually does

This flaw is a local Linux kernel memory-safety issue in AppArmor table creation logic. AppArmor may process a policy/source blob supplied from user space from memory that is not properly aligned for the kernel's access pattern, potentially causing unaligned memory access during conversion or table construction. On affected architectures and configurations, a local authenticated user or process that can trigger AppArmor policy loading or related AppArmor blob parsing may be able to cause kernel instability, including an oops or panic, and may expose sensitive kernel memory contents. The CVSS vector indicates local access, low attack complexity, required low privileges, no user interaction, high confidentiality impact, and high availability impact, with no direct integrity impact described.

Why it matters to the business

The primary operational risk is disruption of Linux systems through crashes or kernel faults, especially on workloads that rely on AppArmor for mandatory access control. A successful attack could also expose sensitive information from kernel memory, increasing the risk of credential, key, or workload data exposure depending on what memory is disclosed. Because exploitation requires local access and there is no known KEV listing, ransomware association, or mature public exploit indicated, this is lower urgency than an internet-facing remote code execution issue; however, it should still be prioritized on shared Linux systems, multi-user servers, container hosts, developer workstations, and systems where untrusted local users or workloads can interact with AppArmor policy loading paths.

How an attack unfolds

An attacker first obtains local execution on an affected Linux system with enough privilege to reach the AppArmor policy/blob parsing path, such as through a local account, compromised service account, container escape-adjacent capability, or another foothold that can influence AppArmor profile loading or related kernel interfaces. The attacker then supplies or causes processing of a crafted AppArmor source blob that is intentionally positioned or structured so that the kernel reads data from an unaligned memory address during table creation. If the vulnerable code path is reached, the kernel may perform unsafe unaligned accesses, resulting in a kernel oops, panic, or other fault condition. Depending on architecture and runtime behavior, the same class of bug may also allow sensitive memory contents to be exposed. There is currently no indication from the provided data that this vulnerability is in CISA KEV, used in ransomware campaigns, or has mature public exploitation, and the EPSS score is very low, so exploitation is more likely to require targeted local access and system-specific conditions than broad automated exploitation.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the AppArmor fix for safe table creation from potentially unaligned user-space memory. No exact fixed package versions were provided, so use vendor advisories and distribution security trackers to identify the corrected kernel builds for each affected platform. Reboot systems after installing the fixed kernel, unless a vendor-supported live-patching mechanism explicitly covers this issue. Where immediate patching is not possible, reduce exposure by limiting local user access, restricting who can load or modify AppArmor profiles, minimizing privileged containers or workloads that can interact with AppArmor policy mechanisms, and monitoring for kernel faults related to AppArmor. Disabling AppArmor is generally not recommended as a mitigation because it may remove an important security control; consider it only as a temporary, risk-assessed operational workaround if advised by the vendor and if the vulnerable functionality cannot otherwise be reached.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor release that includes the AppArmor unaligned-memory-access fix, not merely that the package is installed on disk. On Linux systems, compare `uname -r` with the installed kernel package version and the relevant distribution advisory. Confirm the system has been rebooted into the fixed kernel or that an applicable live patch is active. Review vendor changelogs or kernel patch metadata for the AppArmor fix related to table creation from possibly unaligned memory. To assess exposure before patching, determine whether AppArmor is enabled using tools such as `aa-status`, check whether AppArmor policy loading is used on the system, and identify local users, automation, or container runtimes that can influence AppArmor profiles. A safe validation approach should avoid attempting to trigger kernel crashes in production; use vendor-provided regression tests or a non-production test system if exploitability testing is required.

Typical attack path

1. Gain local execution on a Linux system running an affected kernel with AppArmor enabled or available.
2. Obtain the ability to trigger AppArmor policy loading, replacement, or blob parsing through legitimate interfaces or a compromised privileged/local context.
3. Prepare a malformed or specially arranged AppArmor source blob that causes table creation to read from possibly unaligned memory.
4. Submit or cause the system to process the crafted AppArmor data.
5. Trigger a kernel fault, oops, panic, or potential sensitive memory exposure when the vulnerable code path performs unaligned access.
6. Use the resulting denial of service to disrupt workloads, or use any exposed memory contents to support further compromise if disclosure is achievable in the target environment.

How to detect it

Evidence of exploitation is most likely to appear as kernel instability correlated with AppArmor policy loading or profile replacement. Review `dmesg`, `journalctl -k`, `/var/log/kern.log`, `/var/log/syslog`, and distribution-specific crash logs for AppArmor-related kernel oops, panic, alignment fault, BUG, or general protection fault messages. Review audit logs such as `/var/log/audit/audit.log` for AppArmor profile load, replace, or parser activity shortly before kernel faults. Investigate unexpected invocations of AppArmor management tooling, especially `apparmor_parser`, `aa-enforce`, `aa-complain`, `aa-disable`, package maintainer scripts that reload profiles, or container runtime operations that apply AppArmor profiles. Correlate these events with local account logons, sudo activity, service account activity, container lifecycle events, and recent changes to files under AppArmor profile directories. Because no mature public exploit or specific exploit artifact is indicated, detection should focus on behavioral patterns: anomalous local attempts to load malformed AppArmor profiles, repeated kernel crashes tied to AppArmor operations, and suspicious privilege paths that allow untrusted users to influence AppArmor policy parsing.

• apparmor_parser
• aa-enforce
• aa-complain
• aa-disable
• /etc/apparmor.d/
• /var/cache/apparmor/
• /var/log/audit/audit.log
• /var/log/kern.log
• /var/log/syslog
• apparmor="STATUS"
• operation="profile_load"
• operation="profile_replace"
• AppArmor parser error
• apparmor:
• BUG: kernel NULL pointer dereference
• Kernel panic
• Oops:
• general protection fault
• alignment fault
• unaligned access

What your security team should do

• Patch affected Linux kernels through vendor-supported updates and reboot into the fixed kernel as the primary remediation.
• Prioritize shared Linux servers, container hosts, multi-user systems, build runners, bastion hosts, and systems where untrusted local workloads may execute.
• Verify whether AppArmor is enabled and whether local users or automation can load, replace, or influence AppArmor profiles.
• Restrict AppArmor profile management to trusted administrative paths and review sudoers, automation, and container runtime permissions that may grant profile-loading capabilities.
• Monitor kernel logs for AppArmor-related oops, panic, general protection fault, alignment fault, or BUG messages until all affected systems are patched.
• Because this is not listed as KEV, has no indicated ransomware use, and has a very low EPSS score, track it as important local-hardening work rather than emergency internet-wide remediation unless local threat exposure is high.
• Include this vulnerability in kernel patch compliance reporting, ensuring validation checks the running kernel after reboot rather than only installed packages.
• For high-assurance environments, conduct post-patch regression testing of AppArmor policy loading and enforcement to ensure security controls remain operational.