CVE-2026-47335

What it actually does

This vulnerability is a local denial-of-service flaw in Ubuntu Linux 6.8 kernels that include Ubuntu-specific SAUCE patches for AppArmor notification handling. An unprivileged local user can trigger a NULL pointer dereference in kernel-space AppArmor notification code, causing an oops or kernel panic. Successful exploitation does not provide code execution, privilege escalation, or data access, but it can abruptly crash the affected system and interrupt all workloads running on it.

Why it matters to the business

The primary risk is service outage: any user or process with local access to an affected Ubuntu system may be able to crash the host, causing downtime, failed jobs, interrupted sessions, and potential data loss for in-flight operations. The CVSS availability impact is high, but current external exploitation signals are low: it is not listed in CISA KEV, is not associated with ransomware, has very low EPSS, and no public exploit maturity is reported. Exposure is most important on shared Linux servers, developer workstations, multi-user systems, bastion hosts, CI/CD runners, and environments where untrusted users or workloads can obtain local shell or process execution.

How an attack unfolds

An attacker first needs local execution on an affected Ubuntu Linux 6.8 system. This could be a normal interactive account, a compromised low-privilege account, a local workload, or a process running under restricted privileges. The attacker then exercises the AppArmor notification path in a way that reaches the vulnerable Ubuntu SAUCE patch logic. Because the kernel code mishandles a NULL pointer condition, the dereference occurs in kernel context and the system may panic. The result is a denial of service: the machine becomes unavailable until it is rebooted or otherwise recovered. There is no indication from the provided information that the flaw enables privilege escalation, arbitrary code execution, or remote exploitation by itself.

How to fix it

Apply the appropriate Ubuntu kernel update when Canonical publishes a fixed package for the affected Ubuntu Linux 6.8 kernel line. Because no fixed version was provided in the input, administrators should track the relevant Ubuntu Security Notice and upgrade to the first kernel package version that explicitly includes the fix for this issue. After updating, reboot into the patched kernel and remove or de-prioritize vulnerable kernels from the bootloader where operationally appropriate. If immediate patching is not possible, reduce local attack opportunities by limiting shell access, restricting untrusted local users and workloads, enforcing least privilege, isolating multi-tenant workloads, and monitoring for repeated local crashes. Disabling or weakening AppArmor is generally not recommended as a mitigation unless specifically directed by the vendor, because it can reduce overall system security.

How to confirm the fix worked

Confirm exposure by checking whether systems are running an affected Ubuntu Linux 6.8 kernel that includes the vulnerable AppArmor notification patches. Use package management and kernel version checks such as `uname -r`, `dpkg -l 'linux-image*'`, `apt list --installed 'linux-image*'`, and Ubuntu security advisory metadata once available. Confirm remediation by verifying the running kernel version after reboot is the vendor-fixed version, not merely that the package is installed. Review `/proc/cmdline`, bootloader entries, and package state to ensure systems have actually booted into the patched kernel. Where feasible, validate that AppArmor remains enabled and functioning after the upgrade using standard AppArmor status tooling. Do not rely on remote network scanning alone, because this is a local vulnerability and exposure depends on the running kernel and local access model.

Typical attack path

1. Obtain low-privilege local access to an affected Ubuntu Linux 6.8 system.
2. Identify that AppArmor is present and that the running kernel includes the vulnerable AppArmor notification handling code.
3. Trigger the AppArmor notification handling path with crafted local activity.
4. Cause the vulnerable kernel code to dereference a NULL pointer.
5. Force a kernel oops or panic, making the host unavailable until recovery or reboot.

How to detect it

To determine whether this was already exploited, review host-local telemetry rather than perimeter network logs. Focus on `journalctl -k`, `/var/log/kern.log`, `/var/log/syslog`, crash dumps, `kdump` output, `systemd` reboot records, and uptime/reboot history. Look for kernel oops or panic events containing NULL pointer dereference messages near AppArmor notification activity, followed by abrupt reboot or service interruption. Correlate crash times with local login records, SSH sessions, sudo activity, cron jobs, CI/CD runner activity, container build activity, and user-launched processes. Useful sources include `journalctl --list-boots`, `last -x`, authentication logs, auditd logs if enabled, AppArmor logs, and endpoint detection telemetry showing processes active immediately before the panic. Absence of logs may occur if the panic prevented flushing to disk; in that case, rely on centralized logging, serial console logs, hypervisor console output, crash dumps, or infrastructure power/reboot events. There are no known named threat actors, ransomware campaigns, or public exploit artifacts provided for this issue, so detection should center on crash forensics and local activity correlation.

• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops: 0000
• unable to handle kernel NULL pointer dereference
• apparmor
• AppArmor
• audit: type=1400
• /var/log/kern.log
• /var/log/syslog
• journalctl -k
• journalctl --list-boots
• last -x
• kdump
• /var/crash/

What your security team should do

• Prioritize patching affected Ubuntu Linux 6.8 systems that allow local users, SSH access, developer access, CI/CD jobs, shared hosting, container build workloads, or other untrusted local execution.
• Track Canonical Ubuntu security advisories for the fixed kernel package version, then schedule kernel upgrades and required reboots through normal change windows.
• Inventory all Ubuntu systems running Linux 6.8 kernels and distinguish currently running kernels from merely installed packages.
• Review access controls for systems that cannot be patched immediately; remove unnecessary local accounts, restrict SSH access, and limit execution by untrusted users or jobs.
• Monitor kernel, systemd journal, and crash logs for NULL pointer dereferences, AppArmor-related oops messages, and unexpected reboots or panics.
• Ensure high-availability, job retry, and recovery procedures are in place for business-critical hosts until patching is complete.
• Because current exploitation indicators are low and the issue is not KEV-listed, prioritize based on local-access exposure and business criticality rather than broad internet exposure.