CVE-2026-46173: exit: prevent preemption of oopsing TASK_DEAD task
In the Linux kernel, the following vulnerability has been resolved: exit: prevent preemption of oopsing TASK_DEAD task When an already-exiting task oopses, make_task_dead() currently calls do_task_dead() with preemption enabled. That is forbidden: do_task_dead() calls __schedule(), which has a comment saying "WARNING: must be called with preemption disabled!". If an oopsing task is preempted in do_task_dead(), between becoming TASK_DEAD and entering the scheduler explicitly, bad things happen: finish_task_switch() assumes that once the scheduler has switched away from a TASK_DEAD task, the task can never run again and its stack is no longer needed; but that assumption apparently doesn't hold if the dead task was preempted (the SM_PREEMPT case). This means that the scheduler ends up repeatedly dropping references on the dead task's stack, which can lead to use-after-free or double-free of the entire task stack; in other words, two tasks can end up running on the same stack, resulting in various kinds of memory corruption. (This does not just affect "recursively oopsing" tasks; it is enough to oops once during task exit, for example in a file_operations::release handler)
HarborGuard Analysis
HarborGuard analysisSynopsis
A use-after-free and double-free vulnerability exists in the Linux kernel's task-exit path. When a task that is already exiting encounters a kernel oops, the scheduler can preempt it between the point it is marked TASK_DEAD and the point it explicitly yields the CPU, violating the scheduler's invariant that a TASK_DEAD task never runs again. This causes the kernel to repeatedly drop references on the dead task's stack, allowing two tasks to share the same stack and producing memory corruption that enables privilege escalation, arbitrary data reads, or a kernel panic. A patched-image rebuild is available on HarborGuard for affected environments running fixed versions 6.6.140, 6.12.88, or 6.18.30 and later.
HarborGuard Coverage
Detection is available across every HarborGuard environment. CVE-2026-46173 is ingested from upstream advisory feeds within minutes of publication and matched against all customer images, including custom-built images that bundle an affected kernel version.
AvailableHarborGuard scores this CVE at CVSS 7.8 HIGH and weights it against each environment's compliance policy to determine urgency and routing. Findings are directed to the appropriate team inbox within each customer organization based on configured escalation rules.
AvailableFor environments running an affected kernel version, a patched-image rebuild at the applicable fix version (6.6.140, 6.12.88, or 6.18.30) becomes available as soon as HarborGuard ingests the updated base image. For customers who opt into auto-remediation, HarborGuard runs the rebuild, executes a regression test suite, and opens a pull request against affected workloads automatically.
AvailableExploit Conditions
- Network reachabilityNot required
The attacker needs an existing shell or process on the host; no network access is required to trigger the vulnerable code path.
- AuthenticationRequired
Any low-privilege local account is sufficient to trigger the oops in the task-exit path, for example via a file_operations release handler.
- Victim interactionNot required
No user interaction is needed; the attacker triggers the vulnerability entirely through their own process execution.
- Attack complexityDetail
Attack complexity is low, meaning the exploit is reliable and does not depend on race conditions or specific memory-layout prerequisites beyond having a local process that can induce a kernel oops during exit.
Blast Radius
- Reads kernel memory, including credentials, keys, and other tasks' private data, due to the stack aliasing condition.
- Writes to kernel memory via the shared stack, allowing modification of kernel data structures and privilege escalation to root.
- Crashes the affected host through uncontrolled memory corruption when two tasks execute concurrently on the same stack.
- Corrupts kernel heap state in ways that can persist across process boundaries, affecting workloads co-located on the same node.
How HarborGuard Handles This
Available on HarborGuard: detection fires within minutes of CVE publication and matches against every image in a customer registry or CI pipeline, including images built on custom kernel base layers. Where compliance policy permits, triage is automatically weighted and routed at CVSS 7.8 HIGH priority. For customers who opt into auto-remediation, HarborGuard generates a rebuilt image at the appropriate fix version (6.6.140, 6.12.88, or 6.18.30 depending on the branch in use), runs a regression test suite against the rebuilt image, and opens a pull request against affected workloads. Median time from CVE publication to merged patch PR for high-severity issues is around 90 minutes for environments with auto-remediation enabled. For environments where an immediate kernel upgrade is not possible, compensating controls include restricting local shell access to untrusted users via namespace isolation or seccomp profiles, which reduce the attacker's ability to trigger the oops condition in a controlled way.
Metrics
- CVSS v3.1
- 7.8
- Severity
- HIGH
- Fixed in
- 0
- Affected Products
- 2
Fix available
- Linux / Linux< 640b4c00fb0e2920327435f6176cbefc3c546165 (from 7f80a2fd7db9a55894fd841915236aca611291b5) · < 7b2800ba5f5f77a8ee7f4cbadb19cf1264597a34 (from 7f80a2fd7db9a55894fd841915236aca611291b5) · < 6f49f94f3b11fe8bff1bf2a054143789e76aaf17 (from 7f80a2fd7db9a55894fd841915236aca611291b5) · < 9756b3db5db6c2f5eccb32dddbd88eb4c54f575e (from 7f80a2fd7db9a55894fd841915236aca611291b5) · < c1fa0bb633e4a6b11e83ffc57fa5abe8ebb87891 (from 7f80a2fd7db9a55894fd841915236aca611291b5)
- Linux / Linux5.17Fixed in 0, 6.6.140, 6.12.88, 6.18.30, 7.0.7, 7.1-rc4
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H