CVE-2026-47334

What it actually does

This flaw is a local denial-of-service vulnerability in Ubuntu Linux kernels carrying AppArmor SAUCE notification-handling patches. The affected code can sleep while holding a spinlock, which violates kernel locking rules and can cause a kernel panic, soft lockup, hard lockup, or deadlock. Exploitation requires local code execution by a low-privileged user, does not require user interaction, and primarily impacts system availability rather than confidentiality or integrity.

Why it matters to the business

A low-privileged local user or malware that has already gained a foothold on an affected Ubuntu system may be able to crash or freeze the host. For business operations, this can mean unexpected service outages, failed workloads, interrupted CI/CD jobs, degraded fleet stability, or forced reboots. The risk is currently moderated by the local-access requirement, low EPSS score, lack of known KEV listing, and no public exploit maturity reported, but internet-facing services, multi-user systems, shared compute platforms, and container hosts should still prioritize remediation because a local foothold can be enough to disrupt critical workloads.

How an attack unfolds

An attacker first obtains local access to an affected Ubuntu Linux system as an unprivileged user, for example through stolen credentials, a compromised application account, an exposed shell, or post-exploitation malware. The attacker then exercises AppArmor notification-handling behavior in a way that reaches the vulnerable kernel path. Because the affected AppArmor patch can sleep while a spinlock is held, the kernel may enter an invalid scheduling state, panic, or deadlock. A successful attack does not provide elevated privileges by itself, but it can render the host unavailable until it is rebooted or otherwise recovered.

How to fix it

Apply the vendor-provided Ubuntu kernel security update when available and reboot into the fixed kernel. Because no fixed versions were provided in the input, administrators should consult Canonical Ubuntu Security Notices and package changelogs for the affected kernel streams and confirm the installed kernel no longer contains the vulnerable AppArmor SAUCE notification-handling code. As interim mitigations, restrict untrusted local shell access, reduce the number of users able to execute arbitrary code on shared hosts, isolate high-risk workloads, monitor for kernel lockup or panic events, and consider disabling or limiting AppArmor notification features only if operationally acceptable and recommended by the vendor. Do not rely on service restarts alone; kernel vulnerabilities require booting into a patched kernel to be remediated.

How to confirm the fix worked

Confirm exposure by checking the running Ubuntu kernel version and installed kernel package against Canonical advisories for this issue. Verify remediation by ensuring the system has installed the corrected kernel package and has been rebooted into that kernel, not merely staged the update on disk. Validate with commands such as checking the active kernel version, reviewing installed linux-image package versions, and confirming AppArmor status. Review system logs after patching for absence of recurring kernel warnings, AppArmor notification-related crashes, soft lockups, hard lockups, or panic traces. In fleet environments, inventory should distinguish installed kernel version from currently running kernel version, because systems may remain vulnerable until rebooted.

Typical attack path

1. Gain local, low-privileged execution on an affected Ubuntu Linux host.
2. Identify that the host is running an affected Ubuntu kernel with AppArmor enabled and the vulnerable SAUCE notification handling code present.
3. Trigger AppArmor notification behavior from user space using crafted local activity or repeated policy-mediated operations.
4. Cause the kernel to sleep while holding a spinlock in the vulnerable path.
5. Induce a kernel panic, hang, deadlock, or lockup, resulting in service disruption or host reboot.

How to detect it

To determine whether this vulnerability may already have been exploited, review host-level logs and crash artifacts for unexplained kernel panics, hangs, soft lockups, hard lockups, and AppArmor-related stack traces. Useful sources include journald, syslog, kern.log, dmesg output, kernel crash dumps, kdump/vmcore artifacts, systemd reboot history, and monitoring alerts for unexpected host restarts or watchdog resets. Look for messages indicating sleeping in atomic context, invalid scheduling while atomic, spinlock-related warnings, AppArmor notification paths, kernel oopses, or lockups near the time of service disruption. Because exploitation requires local execution, correlate kernel crash times with authentication logs, sudo logs, shell history where available, process accounting, auditd events, container runtime logs, and EDR telemetry showing local user activity shortly before the crash. There are no known public threat actors, KEV listing, or ransomware campaign associations provided for this issue, so detection should focus on behavioral evidence of local triggering and kernel failure rather than a single network indicator.

• BUG: sleeping function called from invalid context
• scheduling while atomic
• in_atomic()
• preempt_count
• spinlock
• soft lockup
• hard LOCKUP
• kernel panic
• Kernel panic - not syncing
• Oops:
• RCU stall
• blocked for more than
• AppArmor
• apparmor
• apparmorfs
• /var/log/kern.log
• /var/log/syslog
• /var/crash/
• /proc/vmcore
• systemd-journald
• watchdog: BUG: soft lockup
• watchdog: Watchdog detected hard LOCKUP

What your security team should do

• Prioritize patching and rebooting affected Ubuntu systems that allow multiple users, run shared compute workloads, host containers, or support critical services.
• Use asset inventory to identify Ubuntu systems running affected kernel streams and AppArmor-enabled workloads.
• Monitor kernel, syslog, journald, and crash dump sources for panic, lockup, deadlock, or AppArmor-related traces that may indicate attempted exploitation or instability.
• Restrict local access for untrusted users and investigate unusual shell access, newly created accounts, or post-exploitation activity that could provide the prerequisite local foothold.
• Ensure incident response playbooks treat unexplained kernel panics on affected systems as potentially security-relevant, not only as reliability incidents.
• Track Canonical advisories for exact fixed package versions and deploy the relevant linux-image, linux-modules, and associated kernel packages consistently across the fleet.