CVE-2026-46328

What it actually does

This is a local Linux kernel AppArmor resource-limit enforcement flaw affecting POSIX CPU timers. A low-privileged local user or process subject to an AppArmor profile may be able to trigger incorrect handling of CPU rlimits because POSIX CPU timers are not updated when the limit changes. The practical effect is an AppArmor policy-enforcement gap that can allow excessive CPU consumption or inconsistent CPU-limit behavior, causing denial of service and potentially limited integrity impact through bypass of intended confinement controls. It does not provide remote code execution and requires local code execution privileges.

Why it matters to the business

Systems that run untrusted local workloads, shared shell access, containers, CI jobs, build workers, hosting platforms, or multi-user Linux servers are most exposed because a low-privileged workload may consume more CPU than intended and degrade service availability. The issue is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity in the provided data, but the CVSS availability impact is high, so internet-facing multi-tenant infrastructure and high-density Linux hosts should still prioritize kernel updates during the next appropriate maintenance window.

How an attack unfolds

An attacker first obtains the ability to run code as a low-privileged local user or inside a constrained workload on a Linux system using AppArmor. They identify that the process is governed by CPU rlimits intended to restrict resource consumption. The attacker then uses process behavior involving POSIX CPU timers and rlimit changes to reach the vulnerable kernel path where AppArmor updates the rlimit without properly updating the associated POSIX CPU timer state. If successful, the workload can continue consuming CPU beyond the intended policy boundary or cause inconsistent enforcement, degrading host performance or denying service to other workloads. Exploitation is local and depends on the presence of AppArmor confinement and applicable CPU rlimit configuration.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes the AppArmor fix for POSIX CPU timer rlimit handling. Because fixed versions were not provided in the input, use vendor advisories and package changelogs to identify the first kernel build containing the backport for CVE-2026-46328, then reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by avoiding execution of untrusted local workloads, enforcing CPU controls outside AppArmor using cgroups, systemd CPUQuota, container CPU limits, scheduler quotas, and workload isolation, and monitoring or restricting users/processes that can change rlimits via setrlimit or prlimit. Kernel live patching may be acceptable if the vendor explicitly states that this fix is included and active without reboot; otherwise plan a reboot.

How to confirm the fix worked

Confirm remediation by verifying the running kernel, not just the installed package, is at a vendor-fixed build using commands such as uname -r and the platform package manager. Review vendor kernel changelogs or security advisories for the AppArmor POSIX CPU timer rlimit fix. On systems where safe testing is permitted, validate that an AppArmor-confined test workload with CPU rlimits is terminated or throttled as expected when using POSIX CPU timers and CPU-bound execution. Also verify that compensating controls such as cgroup or systemd CPU limits remain active for untrusted workloads.

Typical attack path

1. Gain low-privileged local code execution on a Linux host where AppArmor is enabled.
2. Run or place a process under an AppArmor profile that uses CPU-related rlimits.
3. Manipulate CPU-limit behavior through process execution patterns involving POSIX CPU timers and rlimit changes.
4. Trigger the vulnerable kernel path where CPU rlimit updates are not correctly reflected in POSIX CPU timer handling.
5. Consume excessive CPU or bypass expected confinement limits, causing service degradation or local denial of service.

How to detect it

There are no unique public exploit artifacts provided for this vulnerability, so detection should focus on behavioral evidence of attempted or successful resource-limit bypass. Review kernel logs, journald, syslog, auditd, AppArmor audit events, EDR telemetry, process accounting, and container runtime logs for AppArmor-confined processes that repeatedly consume high CPU, exceed expected runtime, or behave differently from configured CPU limits. If syscall auditing is enabled, look for suspicious use of setrlimit, prlimit64, timer_create, timer_settime, and CPU-time timer activity by untrusted users or confined services followed by sustained CPU saturation. Correlate high CPU events with AppArmor profile names, user IDs, container IDs, service units, and process ancestry. Also review for secondary impact such as service watchdog restarts, systemd unit failures, kernel OOM pressure, degraded host responsiveness, and scheduler starvation affecting neighboring workloads.

What your security team should do

• Inventory Linux systems that have AppArmor enabled, especially shared, multi-user, container, CI/CD, build, hosting, or compute-worker systems.
• Patch affected Linux kernels through the operating system vendor and reboot into the fixed kernel during the next maintenance window; prioritize multi-tenant and untrusted-workload hosts.
• Use cgroups, systemd CPUQuota, container CPU limits, and scheduler controls as defense-in-depth rather than relying only on AppArmor rlimits for CPU containment.
• Review auditd, syslog, journald, EDR, and process accounting data for unusual high-CPU activity from AppArmor-confined processes since the publication date.
• If patching is delayed, restrict local access and untrusted workload execution on systems where CPU exhaustion would have high operational impact.