CVE-2026-46173

What it actually does

This Linux kernel flaw is a local memory corruption issue in task exit handling. If a process triggers a kernel oops while it is already exiting, the kernel can call the scheduler with preemption still enabled after the task has transitioned to TASK_DEAD. Under those conditions, scheduler cleanup logic may incorrectly treat the dead task stack as no longer runnable and repeatedly drop references to it, potentially causing use-after-free or double-free of the task stack. The result can be kernel memory corruption, including scenarios where two tasks run on the same stack. Because exploitation requires local code execution with low privileges, the primary technical risk is local privilege escalation, kernel crash, or system instability.

Why it matters to the business

A local attacker who already has the ability to run code on an affected Linux system may be able to escalate privileges, corrupt kernel memory, or crash the host. For businesses, this can lead to compromised servers, container hosts, workstations, or embedded Linux systems, with potential unauthorized access to sensitive data, disruption of workloads, and loss of trust in system integrity. The vulnerability is not currently listed in CISA KEV, has low EPSS, and no public exploit maturity is reported, but kernel memory corruption flaws should still be prioritized on multi-user systems, shared compute platforms, internet-facing servers where an attacker may first obtain a foothold, and environments running untrusted workloads.

How an attack unfolds

An attacker first needs local execution on an affected Linux system, such as a shell account, compromised service user, malicious container workload with sufficient kernel attack surface, or execution through another vulnerability. The attacker then causes a process to enter task exit while triggering a kernel oops, for example through a vulnerable kernel path reachable during a file operation release handler or a similar cleanup path. Because the exiting task can be preempted after becoming TASK_DEAD but before it explicitly enters the scheduler, the scheduler may mishandle the dead task's stack. With careful timing and heap or stack layout manipulation, an attacker may attempt to turn the resulting use-after-free or double-free condition into controlled kernel memory corruption. Successful exploitation could allow privilege escalation to root or arbitrary kernel code execution; unsuccessful attempts are likely to produce kernel oopses, panics, crashes, or system instability.

How to fix it

Upgrade affected Linux kernel builds to a vendor-supported version that includes the upstream fix for preventing preemption when an oopsing TASK_DEAD task enters do_task_dead(). Because no exact fixed versions were provided, use the relevant distribution or kernel vendor advisory to identify the corrected package for each deployed kernel stream. Prioritize updates for multi-user systems, container hosts, virtualization hosts, CI/build workers, bastion hosts, developer workstations, and systems where untrusted users or workloads can execute code. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads, enforcing container isolation hardening, disabling unnecessary kernel attack surface, applying least privilege, using LSM controls such as SELinux or AppArmor, and ensuring rapid reboot capability for unstable hosts. These mitigations reduce exploitability but do not remove the underlying kernel flaw.

How to confirm the fix worked

Confirm remediation by verifying that each system is running a kernel package from the vendor advisory that includes the fix, not merely that a package is installed on disk. Check the active kernel with commands such as `uname -r` and compare it to the fixed vendor kernel version after reboot. Review package manager history to confirm the corrected kernel was installed and the host was rebooted into it. For source-built kernels, confirm the relevant exit/task-death scheduling fix is present in the kernel source tree and that the running kernel was rebuilt and deployed from that source. Validate exposure by inventorying Linux kernel versions across fleets and identifying systems still running pre-fix kernels, especially where local users, containers, or externally reachable services may provide an attacker with local execution.

Typical attack path

1. Obtain local code execution on an affected Linux system as an unprivileged or low-privileged user.
2. Identify a reachable kernel path that can oops while the current task is exiting, such as cleanup or release-time kernel code.
3. Repeatedly trigger process exit and the oops condition to hit the vulnerable scheduling window.
4. Use timing, CPU scheduling, and memory layout manipulation to influence reuse or corruption of the task stack.
5. Convert the kernel memory corruption condition into privilege escalation, kernel code execution, or denial of service.
6. Cover tracks by removing exploit tooling and relying on kernel crash or oops noise to obscure the attempt.

How to detect it

Detection should focus on evidence of attempted triggering rather than a single definitive network indicator, because exploitation is local and kernel-level. Review kernel logs from journald, syslog, dmesg, persistent crash logs, and crash dump infrastructure for oopses or panics occurring during task exit, scheduler activity, or file release cleanup. Look for repeated oops events from the same user, process name, service account, container, or workload shortly before privilege changes, unexpected root shells, new setuid binaries, credential tampering, or host instability. Useful log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, `kdump`/`crash` artifacts, auditd process execution logs, EDR telemetry, container runtime logs, and authentication logs. Investigators should correlate kernel oops messages mentioning TASK_DEAD, do_task_dead, make_task_dead, finish_task_switch, scheduler activity, stack corruption, use-after-free, double-free, or KASAN reports with local process execution bursts. Because failed exploitation may crash or reboot the host, also review reboot history, panic records, vmcore files, and abnormal service restarts. There are no reliable remote network IOCs for this vulnerability.

• make_task_dead
• do_task_dead
• TASK_DEAD
• finish_task_switch
• BUG: scheduling while atomic
• kernel BUG
• Oops:
• Kernel panic - not syncing
• general protection fault
• use-after-free
• double-free
• KASAN: use-after-free
• KASAN: double-free
• stack corruption
• corrupted stack
• /var/crash
• /var/lib/systemd/coredump
• /proc/vmcore
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory all Linux systems and map running kernel versions, prioritizing internet-facing servers, multi-user systems, container hosts, virtualization hosts, and privileged infrastructure.
• Apply vendor kernel updates that include the fix and reboot systems into the patched kernel; stale running kernels remain vulnerable even after package installation.
• Treat suspicious kernel oopses or panics during process exit, file release, or task cleanup as potential exploitation attempts, especially when correlated with untrusted local code execution.
• Harden local execution paths by reducing shell access, restricting untrusted containers, enforcing SELinux/AppArmor profiles, and limiting low-privileged users' ability to load code or stress kernel interfaces.
• Increase monitoring for repeated kernel oops, BUG, KASAN, use-after-free, double-free, task stack, scheduler, or TASK_DEAD messages in system logs.
• For high-risk shared compute environments, consider temporarily moving untrusted workloads off unpatched hosts until patched kernels are active.
• Ensure crash dumps, kernel logs, and audit logs are retained long enough to investigate suspected local privilege escalation attempts.