findInArray and findKeyInMap accept any *CandidateNode but produce
wrong results when called on the wrong Kind: findInArray uses stride 1,
correct for SequenceNodes but dangerous on MappingNodes (where
key-value pairs live at even-odd indices); findKeyInMap uses stride 2,
correct for MappingNodes but silently skips elements in SequenceNodes.
Commit b0ba9589 fixed two call sites that passed MappingNodes to
findInArray, but nothing prevents the same mistake from recurring.
Each function now logs a warning and returns -1 on a Kind mismatch,
surfacing misuse in tests and debug output rather than letting it
corrupt results silently.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
recurseNodeObjectEqual and containsObject both used findInArray to
locate keys in a MappingNode's Content array. findInArray steps by 1,
so it matches against both keys (even indices) and values (odd indices).
In recurseNodeObjectEqual, when a null key in the LHS matched a null
value in the RHS at the last position, rhs.Content[indexInRHS+1]
accessed an out-of-bounds index, causing a panic.
In containsObject, a %2 guard prevented the panic but introduced false
negatives: when a null value appeared before the actual null key,
findInArray returned the value's odd index, the guard rejected it, and
the function reported the key as missing.
Both functions now use findKeyInMap, which steps by 2 and compares only
key positions. The %2 guard in containsObject is removed.
Reproducer for the panic (recurseNodeObjectEqual):
echo '? [{~: ~}]
: v1
? [{2: ~}]
: v2' | yq '. += .'
Reproducer for the false negative (containsObject):
printf '? 1\n: ~\n? ~\n: x\n' | yq 'contains({~: "x"})'
Found by OSS-Fuzz via the lima project's FuzzEvaluateExpression target.
https://issues.oss-fuzz.com/issues/383860504
Signed-off-by: Jan Dubois <jan@jandubois.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
