panic: runtime error: index out of range [1] with length 1

[jandubois]

This bug was detected by oss-fuzz and reported in https://issues.oss-fuzz.com/issues/42537678.

There is a PR with a fix in #2112, but it has been closed because it was missing a test case.

The issue with the test case was that both the data and the command were longish strings of garbage created by the fuzzer. I've been able to manually reduce it to:

$ echo $'!!null\n-' | yq $'.\r'
panic: runtime error: index out of range [1] with length 1

goroutine 1 [running]:
github.com/mikefarah/yq/v4/pkg/yqlib.doTraverseMap(0xc0000435e8, 0x9?, {0x7ff7bdf7024c, 0x1}, {0x0, 0x0, 0x0, 0x0, 0x0}, 0x0)
	github.com/mikefarah/yq/v4/pkg/yqlib/operator_traverse_path.go:269 +0x334
github.com/mikefarah/yq/v4/pkg/yqlib.traverseMap({0xc0002dc270, 0x0, 0x0, {0x0, 0x0}}, 0xc00022a0e0, 0xc00022a380, {0x0, 0x0, 0x0, ...}, ...)
	github.com/mikefarah/yq/v4/pkg/yqlib/operator_traverse_path.go:223 +0xe7
…

@mikefarah I'm not sure if you want to include fuzzer-generated tests, and where best to put this. You offered in #2112 to add it yourself if you get a repro scenario, so any help would be appreciated.

The fuzzing results were part of a CNCF sponsored audit, and this issue is mentioned in the report at https://github.com/lima-vm/lima/blob/master/docs/reports/Ada-Logics-Lima-fuzzing-audit-2024.pdf on page 35.

Original reproducer

func TestEvaluateExpressionPoc(t *testing.T) {
        expression := string([]byte{46,13,13})
        content := []byte{13, 63, 13, 13, 13, 13, 13, 13, 45, 45, 45, 10,
                13, 52, 13, 13, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51, 51,
                51, 51, 51, 51, 51, 13, 13, 13, 13, 13, 13, 13, 63, 13, 13, 13,
                13, 13, 13, 45, 45, 45, 64, 13, 122, 45, 46, 45, 10, 13, 13, 13,
                13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 63, 13, 13,
                13, 13, 13, 13, 45, 45, 45, 10, 13, 13, 13, 13, 114, 100, 48,
                13, 13, 13, 13, 63, 13, 13, 13, 13, 13, 13, 45, 45, 45, 10, 13,
                13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 63,
                13, 13, 13, 13, 13, 13, 45, 45, 45, 10, 33, 33, 110, 117, 108,
                108, 13, 13, 13, 13, 13, 35, 45, 51, 10, 51, 45, 45, 10, 13, 13,
                13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 63, 13,
                13, 13, 13, 13, 13, 45, 45, 45, 10, 13, 13, 13, 63, 13, 13, 13,
                13, 13, 13, 45, 45, 45, 13, 13, 45, 45, 45, 64, 13, 122, 45,
                46, 45, 10, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13,
                13, 13, 13, 63, 13, 13, 13, 13, 13, 13, 45, 45, 45, 10, 13, 13,
                13, 13, 114, 100, 48, 13, 13, 13, 13, 63, 13, 13, 13, 13, 13,
                13, 45, 45, 45, 10, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13,
                13, 13, 13, 13, 13, 63, 13, 13, 13, 13, 13, 13, 45, 45, 45, 10,
                33, 33, 110, 117, 108, 108, 13, 13, 45}
        _, _ = EvaluateExpression(expression, content)
}

[mikefarah]

Fixed - not sure about these fuzzer tests, they're quite odd. In this case, it somehow caused the underlying library to create a map that only had a key.

[mikefarah]

Thanks for investigating though :)

[mikefarah]

On looking at the traces for these tests, despite the strange generated inputs I think they are worthwhile fixes 👍🏼

[mikefarah]

Fixed in 4.4.6

[jandubois]

I think they are worthwhile fixes

Ok, when I have time I'll try to see if there are more yq related reports. The fuzzers keep running on spare Google CPU cycles, trying random input, and occasionally file new bugs, but they won't become public for 3 or 6 months, can't remember how long exactly.