CVE-2026-45848

What it actually does

This vulnerability is a local denial-of-service flaw in the Linux kernel AppArmor socket permission path. During socket setup or teardown, AppArmor may evaluate socket permissions through aa_sock_file_perm while the socket object or its underlying sock structure is NULL. If that condition is reached, the kernel can dereference a NULL pointer and trigger an oops or panic, depending on kernel configuration and panic-on-oops settings. The impact is availability loss only: the flaw does not directly provide confidentiality or integrity compromise, and exploitation requires local privileges on the affected system.

Why it matters to the business

A local user or compromised low-privilege process may be able to crash affected Linux systems, disrupting workloads, containers, virtual machines, appliances, or services that rely on kernel AppArmor enforcement. The business risk is highest for multi-user systems, shared hosting, container platforms, CI/CD runners, and internet-facing services where an attacker may first obtain limited local execution and then cause service downtime. The CVSS score is medium, EPSS is very low, it is not listed in CISA KEV, and there is no known public exploit maturity in the provided data, so this should be prioritized as a reliability and hardening fix rather than an active mass-exploitation emergency.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system where AppArmor is enabled or where the vulnerable AppArmor socket mediation path is reachable. The attacker then repeatedly creates, manipulates, and tears down sockets, especially socket types that may pass through older AppArmor mediation paths such as AF_UNIX-related handling or other socket permission checks. By racing socket lifecycle transitions or triggering permission checks during setup or teardown, the attacker attempts to cause AppArmor to evaluate a file/socket permission when the socket pointer or sock structure is NULL. If successful, the kernel dereferences the NULL value inside the AppArmor permission path, causing a kernel oops. On systems configured to panic on oops, this can immediately reboot or halt the host; otherwise, it can destabilize the kernel and affected workloads.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or upstream stable branch that includes the AppArmor fix for NULL socket handling in aa_sock_file_perm. Because no exact fixed versions were provided, use vendor advisories for the deployed distribution and kernel stream to identify the corrected package. Apply the updated kernel package and reboot into the fixed kernel; simply installing the package without rebooting is not sufficient unless live patching is available and confirmed to include this fix. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, using container isolation controls, disabling unnecessary user accounts, and reviewing whether AppArmor profiles and socket mediation features are required for the workload. Disabling AppArmor may avoid the vulnerable path in some configurations but weakens system security and should only be considered as a temporary, risk-accepted workaround after vendor guidance is reviewed.

How to confirm the fix worked

Confirm remediation by verifying that the system is booted into a vendor kernel build that includes the AppArmor NULL socket fix, not merely that an updated package is installed. Use package manager metadata, distribution security advisories, and uname -a or equivalent kernel version checks to confirm the running kernel. Validate AppArmor status with aa-status or equivalent tooling and confirm that normal AppArmor policy enforcement continues after the update. Review kernel logs after reboot for absence of new oops, panic, NULL pointer dereference, or AppArmor-related stack traces involving aa_sock_file_perm. For fleet validation, inventory Linux kernel versions across systems and compare them against the vendor-fixed kernel versions for each distribution and release branch.

Typical attack path

1. Obtain local access to an affected Linux system, such as through a shell, compromised service account, container escape-adjacent foothold, or untrusted multi-user workload.
2. Confirm that the host is running a vulnerable kernel build and that AppArmor is enabled or socket mediation paths are active.
3. Run a local program that rapidly creates, uses, and closes sockets to hit socket setup or teardown timing windows.
4. Trigger AppArmor socket permission evaluation while the socket or underlying sock structure is NULL.
5. Cause a kernel NULL pointer dereference in or near aa_sock_file_perm, resulting in a kernel oops or panic.
6. Leverage the crash to disrupt services, force host reboot, terminate workloads, or degrade availability.

How to detect it

To determine whether this was already exploited, review kernel and system logs for crashes, oops events, or panics that reference AppArmor socket permission handling. Primary sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/syslog, /var/log/messages, crash dump directories such as /var/crash, kdump/vmcore artifacts, and centralized EDR or SIEM kernel-event telemetry. Look for NULL pointer dereference messages, stack traces containing aa_sock_file_perm, AppArmor-related socket permission checks, or repeated kernel crashes shortly after bursts of local socket activity. Correlate crash timestamps with local user sessions, SSH logins, sudo activity, container job starts, CI/CD runner executions, newly created binaries in temporary directories, and unusual processes repeatedly creating UNIX or other local sockets. Because this is a denial-of-service condition rather than a code-execution primitive, durable attacker artifacts may be limited; absence of a suspicious binary does not rule out exploitation if logs show the relevant kernel fault pattern.

• aa_sock_file_perm
• __unix_needs_revalidation
• apparmor: fix NULL sock
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Oops: 0000
• Kernel panic - not syncing
• general protection fault
• AppArmor
• apparmor
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /var/crash
• vmcore
• dmesg

What your security team should do

• Inventory Linux systems using AppArmor and identify kernels that have not received the vendor fix for this vulnerability.
• Prioritize patching for multi-user systems, container hosts, shared build runners, bastion hosts, and systems running untrusted or semi-trusted local workloads.
• Apply the vendor-fixed kernel and reboot systems into the corrected kernel; verify the running kernel after reboot.
• Monitor kernel logs for oops, panic, NULL pointer dereference, and AppArmor stack traces involving aa_sock_file_perm or socket permission checks.
• Limit local execution opportunities by removing unnecessary accounts, tightening SSH access, constraining CI/CD jobs, and isolating untrusted workloads until patching is complete.
• Do not treat this as an internet-facing remote code execution issue based on the provided data; focus response on local availability risk and host hardening.
• Track vendor advisories because fixed package versions vary by Linux distribution and kernel maintenance branch.