Fix out-of-bounds memory access in CIRCULAR_BUFFER with zero slot count

[NEX-S]

BUG=#3695

What

CircularBufferEval computes the buffer shift size as (num_slots - 1) * depth, where num_slots = output->dims->data[1]. CircularBufferPrepare validated the other dimensions but never checked that the output slot count is at least 1.

Why

With num_slots == 0, (num_slots - 1) * depth evaluates to -depth as an int and wraps to a huge size_t when passed to memmove in EvalInt8:

memmove(output, &output[depth], (num_slots - 1) * depth);
memcpy(&output[(num_slots - 1) * depth], input, depth);

This performs a large out-of-bounds read from output + depth and a large out-of-bounds write starting at output. All tensor dimensions come from the model file, so a crafted .tflite model can trigger this (reproduced under ASan as negative-size-param, see #3695). On microcontroller targets, which typically run without mitigations, this is an out-of-bounds write primitive.

Fix

Reject slot counts < 1 in CircularBufferPrepare:

TF_LITE_ENSURE(context, output->dims->data[1] >= 1);

Testing

Added CircularBufferTest.ZeroNumSlotsRejectedInPrepare:

• Fails without the fix (InitAndPrepare returns kTfLiteOk for a [1,0,1,1] output, where it must fail).
• Passes with the fix (Prepare rejects the shape).

Existing tests (4) continue to pass.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.