lists.range(N) in ext/lists.go allocates N elements with no upper bound check. A large value causes OOM and crashes the process.
This is exploitable in Kubernetes ValidatingAdmissionPolicy where user-controlled fields feed into CEL expressions. For example:
validations:
- expression: "lists.range(object.spec.replicas).all(i, i >= 0)"
An attacker sets replicas: 2147483647 and the API server allocates ~16 GB, gets OOM-killed.
The root cause is genRange() at line 406:
func genRange(n types.Int) (ref.Val, error) {
var newList []ref.Val
for i := types.Int(0); i < n; i++ {
newList = append(newList, i)
}
return types.DefaultTypeAdapter.NativeToValue(newList), nil
}The cost estimator doesn't help at Lists v1-v2 because cost estimators for lists.range are only registered at v3+ (line 354). CostLimit is also opt-in.
Confirmed: lists.range(10000000) allocates 865 MB in ~5 seconds.
I'll submit a PR with the fix — adding a maxRangeSize check and rejecting negative values.
lists.range(N)inext/lists.goallocates N elements with no upper bound check. A large value causes OOM and crashes the process.This is exploitable in Kubernetes ValidatingAdmissionPolicy where user-controlled fields feed into CEL expressions. For example:
An attacker sets
replicas: 2147483647and the API server allocates ~16 GB, gets OOM-killed.The root cause is
genRange()at line 406:The cost estimator doesn't help at Lists v1-v2 because cost estimators for
lists.rangeare only registered at v3+ (line 354).CostLimitis also opt-in.Confirmed:
lists.range(10000000)allocates 865 MB in ~5 seconds.I'll submit a PR with the fix — adding a
maxRangeSizecheck and rejecting negative values.