Add U-mode task isolation and fix self-termination

[HeatCrab]

U-mode tasks could previously control other tasks and had no way to properly terminate themselves. This adds permission checks to restrict task control syscalls to self-only operations and enables safe self-termination through the existing zombie task mechanism.

---

Summary by cubic

Locks down U‑mode task control to self-only and adds safe self-termination using the zombie task path. This prevents user tasks from affecting others and ensures proper cleanup.

• Bug Fixes
  • Enforce U‑mode isolation and ID validation: tcancel/tsuspend/tpriority require id == mo_task_id(); invalid ids (<= 0 or > UINT16_MAX) return -EINVAL; others return -EPERM. tresume always returns -EPERM in U‑mode.
  • Safe self-termination: calling mo_task_cancel on self sets TASK_ZOMBIE, yields, and lets the scheduler reclaim it; zombie cleanup skips the current task; id == 0 still returns ERR_TASK_CANT_REMOVE.

^{Written for commit d34b392. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="kernel/task.c">

<violation number="1" location="kernel/task.c:1003">
P1: Marking the current task as TASK_ZOMBIE before _yield() lets dispatch() free the running task in task_cleanup_zombies(), then dereference kcb->task_current->data during context save/scheduling. This introduces a use-after-free on self-termination. Defer freeing the current task until after the context switch or skip cleanup of the current task.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[visitorckw]

Since the syscall interface takes int id (32-bit), but mo_task_id() returns uint16_t, there is a potential aliasing issue here due to the cast.

If a user accidentally passes a large ID like 0x10001 (65537), the check (uint16_t)0x10001 != 1 becomes 1 != 1 (False), allowing the call to proceed. Then, mo_task_cancel(uint16_t id) will receive the truncated value 1 and terminate the current task unexpectedly.

I think it would be safer to enforce an upper bound check or perform the comparison without the cast?

[HeatCrab]

Fixed. Adopted the upper bound check approach and preserved Linmo's original error code semantics.

[visitorckw]

Nit: I don't think we need the (int) cast here due to integer promotion.

[HeatCrab]

To satisfy -Wsign-compare without the (int) cast, adopted the single-check idiom.