CVE-2026-45965

What it actually does

This is a local denial-of-service flaw in the Linux kernel AppArmor subsystem. When AppArmor's binary policy export setting is disabled at runtime, profiles loaded before the change can retain AppArmor filesystem entries that symbolically link to now-invalid raw policy data. If one of those profiles is later replaced and a process attempts to resolve the stale rawdata symlink, the kernel may dereference a NULL profile->rawdata pointer and trigger a kernel oops. Depending on kernel panic-on-oops settings and workload behavior, this can crash the affected process context, destabilize the host, or cause a full system panic/reboot. The issue does not provide confidentiality or integrity impact by itself and requires local privileges or access sufficient to manipulate AppArmor policy/profile state and trigger AppArmor filesystem reads.

Why it matters to the business

An authenticated local user, compromised service account, container escape-adjacent workload with relevant host access, or administrator mistake could make a Linux system running AppArmor unstable or unavailable. On production servers, this may interrupt hosted applications, cause node reboots, evict workloads, disrupt CI/CD runners or container platforms, and increase operational recovery effort. The EPSS score is low and there is no known KEV listing or reported ransomware use, so broad Internet-scale exploitation is unlikely; however, local denial-of-service issues in kernels should still be prioritized on multi-user systems, shared hosting, build infrastructure, and security-sensitive AppArmor-enforced environments.

How an attack unfolds

An attacker first needs local access to an affected Linux system and a way to interact with AppArmor profile management or AppArmor filesystem entries. The vulnerable state occurs when AppArmor profiles are loaded while binary policy export is enabled, then the export_binary parameter is disabled at runtime. A profile that still has rawdata exposed via apparmorfs is then replaced, causing the profile rawdata pointer to be cleared. The attacker or a local process subsequently reads or resolves the stale rawdata symlink under the AppArmor filesystem, such as through readlink, ls, stat, or similar filesystem operations. The kernel follows the AppArmor rawdata symlink path and dereferences profile->rawdata->name even though profile->rawdata is NULL, producing a NULL pointer dereference in kernel mode. This results in a kernel oops and may cause denial of service, especially where panic_on_oops is enabled.

How to fix it

Apply the vendor kernel update that includes the AppArmor fix adding a NULL check before dereferencing profile rawdata. Because no package-specific fixed versions were provided, use the latest stable kernel packages from the Linux distribution or kernel vendor and verify the vendor advisory for CVE-2026-45965. Reboot into the patched kernel after installation; kernel package installation alone is not sufficient if the running kernel is still vulnerable. As interim mitigation, avoid changing AppArmor binary export settings at runtime on affected systems, avoid unnecessary AppArmor profile replacement/reload operations while export_binary is disabled, restrict local access to AppArmor policy management interfaces, and limit access to apparmorfs/debug/security filesystems to trusted administrators only. On systems where availability is critical, review panic_on_oops behavior and operationally plan for controlled patch reboots rather than unplanned crashes.

How to confirm the fix worked

Confirm the system is running a kernel build that contains the AppArmor rawdata NULL-dereference fix, not merely that the package is installed. Validate with distribution tools such as uname -r, package manager changelogs, vendor CVE trackers, and kernel build metadata. Check whether AppArmor is enabled and active using AppArmor status tools and by verifying the presence of AppArmor securityfs entries. Where safe and approved in a test environment only, reproduce the pre-fix state by loading profiles, toggling binary export, replacing a profile, and resolving AppArmor rawdata symlinks; a patched kernel should not oops. In production, avoid exploit-style validation and instead rely on kernel version, vendor advisory mapping, and absence of new kernel log messages referencing rawdata_get_link_base, rawdata_get_link_data, or NULL pointer dereference in AppArmor code paths after patching and rebooting.

Typical attack path

1. Obtain local access to a Linux host using an affected kernel with AppArmor enabled.
2. Identify that AppArmor binary policy export has been enabled for previously loaded profiles or that stale AppArmor rawdata links exist.
3. Disable or wait for AppArmor binary export to be disabled at runtime.
4. Replace or reload an AppArmor profile whose rawdata entry was previously exposed.
5. Trigger symlink resolution or metadata access against the stale AppArmor rawdata entry through apparmorfs.
6. Cause the kernel to dereference a NULL rawdata pointer and produce an oops or panic, resulting in service disruption.

How to detect it

Investigate kernel logs and persistent journal data for evidence of a kernel oops, panic, or NULL pointer dereference in AppArmor rawdata symlink handling. Primary sources include dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, crash dump infrastructure such as kdump/vmcore, hypervisor reset events, orchestration node reboot events, and endpoint telemetry capturing kernel panics. Look for stack traces containing rawdata_get_link_base, rawdata_get_link_data, vfs_readlink, do_readlinkat, or __x64_sys_readlink, especially when paired with AppArmor profile reload/replacement activity or audit messages indicating profile loads. Correlate timestamps with administrative actions that changed AppArmor export_binary settings, profile reload commands, package upgrades that reloaded profiles, or local users/processes running ls, readlink, stat, or similar operations against AppArmor filesystem entries. A single kernel oops may be enough to indicate attempted or accidental triggering; repeated crashes around AppArmor profile operations should be treated as suspicious local denial-of-service activity.

• BUG: kernel NULL pointer dereference, address: 0000000000000088
• #PF: supervisor read access in kernel mode
• Oops: Oops: 0000
• RIP: 0010:rawdata_get_link_base
• rawdata_get_link_base.isra.0
• rawdata_get_link_data
• vfs_readlink
• do_readlinkat
• __x64_sys_readlink
• profile->rawdata
• apparmor: fix invalid deref of rawdata when export_binary is unset
• apparmorfs
• export_binary
• /sys/kernel/security/apparmor
• /sys/kernel/security/apparmor/policy
• /sys/kernel/security/apparmor/policy/raw_data
• kernel NULL pointer dereference
• panic_on_oops

What your security team should do

• Prioritize patching shared, multi-user, build, container-host, and AppArmor-enforced Linux systems where local users or workloads are not fully trusted.
• Confirm patched kernel packages are installed and that systems have rebooted into the fixed kernel.
• Restrict AppArmor profile loading, replacement, and runtime configuration changes to trusted administrative users and automation only.
• Search historical kernel logs for AppArmor-related NULL pointer dereference, oops, or panic messages to determine whether the bug has already been triggered.
• Avoid runtime toggling of AppArmor binary export on unpatched systems; schedule changes during maintenance windows after kernel updates.
• Review monitoring for unexpected Linux host reboots, kernel panics, node NotReady events, or workload evictions that align with AppArmor log artifacts.
• Because this is not KEV-listed and has low EPSS, treat it as a risk-based kernel stability issue rather than an emergency Internet-exposed RCE, unless affected systems are shared or locally exposed to untrusted users.