CVE-2026-46173: Linux Kernel Task Exit Scheduler Vulnerability (CVSS 7.8)

Technical summary

CVE-2026-46173 stems from a violation of scheduler preconditions in the Linux kernel's task exit path. The make_task_dead() function calls do_task_dead() with preemption enabled, but do_task_dead() invokes __schedule(), which explicitly requires preemption to be disabled. When an oopsing task becomes TASK_DEAD but is preempted before __schedule() gains control, finish_task_switch() makes incorrect assumptions about task state and stack lifetime. The scheduler then performs repeated reference-count decrements on the dead task's stack (the SM_PREEMPT case), resulting in use-after-free or double-free conditions. This allows two or more tasks to run concurrently on the same kernel stack, enabling arbitrary memory corruption. The vulnerability is not limited to recursive oops scenarios; a single oops during any file operation's release handler or similar exit-time code path is sufficient to trigger the condition.

Business impact

Successful exploitation grants local attackers the ability to cause memory corruption in kernel space from a user-space context. An attacker with local access can craft a process that oopses during exit (for example, by triggering an error in a file_operations::release handler) to achieve privilege escalation, data theft, or denial of service. The vulnerability's HIGH CVSS score (7.8) reflects the combination of local access requirement with high impact across confidentiality, integrity, and availability. Systems where untrusted users can execute code or run containers are at elevated risk. Affected deployments may experience system instability, data corruption, unauthorized privilege acquisition, or service disruptions.

Affected systems

The Linux kernel across all affected versions is susceptible. The vulnerability affects standard kernel builds where the exit and scheduling paths have not been patched. Systems running unpatched Linux kernels—including general-purpose servers, embedded systems, containerized environments, and cloud instances—are in scope. Any Linux distribution shipping an unpatched kernel version is affected; verification against vendor advisories and your specific kernel version is essential.

Exploitability

Exploitation requires local code execution privileges (CWE-787 out-of-bounds write context). An attacker must be able to spawn and execute a process on the target system, then deliberately induce an oops condition during task exit. The bar for triggering the oops is relatively low—error conditions in file_operations release handlers, driver exit paths, or other exit-time kernel code are sufficient. No network vector exists; however, containerized or multi-tenant environments allow untrusted processes to trigger the vulnerability. The kernel does not require special capabilities or elevated privileges to trigger the oops, making it accessible to standard user-level processes in many configurations.

Remediation

Remediation requires applying a Linux kernel patch that ensures preemption is disabled during the do_task_dead() call in make_task_dead(). The fix is a small targeted change to the task exit path, typically implemented by wrapping the problematic code section with preemption disable/enable calls (preempt_disable() and preempt_enable_no_resched() or equivalent). Verify the specific kernel version patch from your Linux distribution's security advisories, as version numbers and backport details vary by vendor.

Patch guidance

1. Check your current kernel version using `uname -r`. 2. Consult your Linux distribution's security advisory for CVE-2026-46173 to identify the patched kernel version for your branch (mainline, stable, LTS, or distribution-specific). 3. Update to the patched kernel version via your package manager (apt, yum, dnf, etc.) or compile from source if running a custom kernel. 4. Reboot the system to load the patched kernel. 5. Verify the fix by confirming the new kernel version no longer carries the vulnerability (review kernel changelog or Git commit history if auditing in-house builds).

Detection guidance

In production, kernel memory corruption from this vulnerability may manifest as: - Unexpected kernel oops or panic messages during process exit, especially in error scenarios. - Memory corruption errors (stack corruption, heap corruption, use-after-free symptoms). - Unexplained privilege escalation attempts or successful privilege escalation from low-privilege processes. - System instability following process exit events or file descriptor close operations. Kern log analysis (dmesg, journalctl) for TASK_DEAD state anomalies or repeated stack reference-count warnings may provide early signals. Proactive mitigation is strongly preferred; detection of active exploitation is difficult without kernel-level instrumentation.

Why prioritize this

This vulnerability merits immediate attention due to its HIGH severity score (7.8) and the ease with which a local attacker can achieve kernel memory corruption leading to privilege escalation. Unlike many kernel vulnerabilities, exploitation does not require specialized kernel knowledge or deep reverse engineering—inducing an oops during process exit is straightforward. Any system permitting untrusted local code execution or multi-tenant workloads is at material risk. The impact spans confidentiality, integrity, and availability, making this a critical control failure if left unpatched.

Risk score, explained

The CVSS v3.1 score of 7.8 (HIGH) reflects: (1) Attack Vector: Local—exploitation requires prior code execution access; (2) Attack Complexity: Low—triggering an oops during exit is relatively straightforward; (3) Privileges Required: Low—no elevated privileges are needed to spawn a malicious process; (4) User Interaction: None—the attack is fully automated once a process is spawned; (5) Confidentiality, Integrity, and Availability impacts all rated High—memory corruption enables arbitrary kernel memory access, modification, and denial of service. The score appropriately reflects a serious local privilege escalation vector that does not affect systems where local code execution is already denied.

Frequently asked questions