T09 · Insecure Skill Coding Practices
Warning
- Location
- references/scheduler.md:68
- Finding
- Concurrency Limit Is Not Enforced by the Resource Allocation Algorithm## Vulnerability Details **File Location**: `references/scheduler.md:68-79` **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Medium **Vulnerable Code**: ```python def allocate_resources(tasks, max_concurrent): """ 分配执行槽 按优先级顺序分配 """ allocated = [] for task in tasks: if len(allocated) >= max_concurrent: allocated.append(task) else: allocated.append(task) return allocated ``` ### Technical Analysis The resource allocation algorithm does not enforce the `max_concurrent` parameter. Both branches of the conditional append the current task to `allocated`, including when the number of allocated tasks has already reached or exceeded the configured limit. Consequently, the function returns every submitted task rather than limiting the allocation to the available execution slots. This contradicts the Skill's documented concurrency controls and removes an intended defense against excessive CPU, memory, I/O, network, and external-service consumption. Although the project contains documentation and example algorithms rather than an executable implementation, directly implementing or following this algorithm would reproduce the flaw. ### Attack Path 1. An attacker or untrusted user submits a large collection of resource-intensive tasks. 2. The scheduler parses and sorts the tasks. 3. The scheduler passes the complete task collection to `allocate_resources()`. 4. Once `len(allocated)` reaches `max_concurrent`, the true branch continues to append tasks instead of deferring them. 5. Every task is returned as allocated. 6. If the downstream execution pool accepts this allocation without an independent limit, excessive tasks run or become active simultaneously. 7. CPU, memory, I/O, network capacity, API quotas, or external-service limits may be exhausted. ### Impact Assessment The issue primarily affects availab ...[truncated 460 chars]
- Remediation
- ## Remediation Suggestions Correct the allocator so it only selects tasks up to the configured capacity and leaves remaining tasks in a pending queue. For example: ```python def allocate_resources(tasks, max_concurrent): if not isinstance(max_concurrent, int) or max_concurrent < 1: raise ValueError("max_concurrent must be a positive integer") allocated = [] pending = [] for task in tasks: if len(allocated) < max_concurrent: allocated.append(task) else: pending.append(task) return allocated, pending ``` Additional hardening should include: - Enforce the same concurrency limit at the actual worker-pool or semaphore boundary rather than relying only on scheduling logic. - Apply per-user and global queue-size limits. - Reject or throttle task batches that exceed configured thresholds. - Apply CPU, memory, I/O, network, and execution-time limits independently. - Require explicit confirmation for large batches containing destructive or externally visible operations. - Add tests proving that active allocations never exceed `max_concurrent`. - Add stress tests covering very large task collections and concurrent submissions. - Monitor active workers, queue depth, resource utilization, rate-limit errors, and task admission failures.