thc1006 created YUNIKORN-3329:
---------------------------------
Summary: Task-group placeholder ask can overflow to a negative
value from an unvalidated task-groups annotation
Key: YUNIKORN-3329
URL: https://issues.apache.org/jira/browse/YUNIKORN-3329
Project: Apache YuniKorn
Issue Type: Bug
Reporter: thc1006
The gang task-group placeholder ask is computed from the
yunikorn.apache.org/task-groups pod annotation without bounding the values.
GetTaskGroupsFromAnnotation (pkg/cache/utils.go) only checks that minMember is
non-zero and non-negative and that minResource is present; it does not check
the resource magnitudes. The ask is then computed in GetTGResource
(pkg/common/resource.go) as minMember * minResource using unchecked int64
accessors, and aggregated across task groups with the unchecked common.Add.
Because both minMember and minResource come unbounded from the annotation, the
ask can wrap to a negative int64 in three places:
* the Quantity.MilliValue() / Value() accessor itself (a cpu of
9223372036854776 has MilliValue() around -9.2e18; a memory of
9223372036854775808 (MaxInt64 + 1) projects to MinInt64),
* the minMember * minResource product,
* the aggregate across task groups (two task groups each requesting 5E memory
sum to 1e19, which wraps negative).
A negative or wrong value is then sent to the core as
AddApplicationRequest.PlaceholderAsk. A negative minResource (for example cpu:
"-1") also produces a negative ask directly, without any overflow.
Expected: an annotation whose placeholder ask cannot be represented as a
non-negative int64 should be rejected with a clear error, not silently turned
into a negative or unrelated ask.
Steps to reproduce: create a pod with a yunikorn.apache.org/task-groups
annotation whose minResource is negative, or large enough that minMember *
minResource (per group or summed across groups) overflows int64. No validation
rejects it, and the placeholder ask sent to the core is negative/wrong.
Fix (in the linked PR): reject the annotation at the parse boundary
(GetTaskGroupsFromAnnotation) when a minResource is negative, when a cpu/other
quantity's int64 accessor would overflow, when minMember * minResource would
overflow, or when the aggregate across task groups would overflow. Saturating
instead of rejecting was considered and dropped, because it would mask an
invalid annotation as a near-infinite gang reservation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
