Verify untrusted embedded flatbuffer/flexbuffer before parsing in detection_postprocessing_graph

[hdk10]

Summary

detection_postprocessing_graph.cc parses two untrusted, model-embedded buffers with no verification,
plus one missing null-check:

1. Nested ObjectDetectorOptions flatbuffer. ConfigureOutModelNmsTensorsToDetectionsCalculator
   and ConfigureSsdAnchorsCalculator call GetObjectDetectorOptions(custom_metadata->data()->data())
   (a bare GetRoot, no Verifier) on the attacker-controlled DETECTOR_METADATA CustomMetadata
   blob. The outer metadata verifier only checks the byte-vector length, not that the bytes form a
   valid nested flatbuffer, so a malformed blob leads to an out-of-bounds read / wild-pointer walk.

2. flexbuffers::GetRoot on custom_options. GetMaxClassesPerDetection calls
   flexbuffers::GetRoot(custom_options->Data(), custom_options->size()) with no
   flexbuffers::VerifyBuffer. GetRoot reads the trailing bytes to seed parsing, so a 0/1-byte
   custom_options underflows before the buffer start.

3. Null custom_code(). The op-code search dereferences custom_code()->str() without checking
   custom_code() != nullptr (an optional field), crashing on a CUSTOM op-code lacking it.

Impact

Out-of-bounds read / null dereference (crash / potential info disclosure) during
ObjectDetector::Create() on a crafted model, before inference.

Change

Verify the ObjectDetectorOptions buffer with VerifyObjectDetectorOptionsBuffer before parsing (both
sites); verify the flexbuffer with flexbuffers::VerifyBuffer before GetRoot; null-check
custom_code(). No behavior change for valid models.

Notes

Reported through the Google OSS VRP (issue 546472889). Verified with AddressSanitizer PoCs against the
GetObjectDetectorOptions and flexbuffers::GetRoot sinks. Analysis was AI-assisted and
human-reviewed; I could not run the full Bazel build locally, so please run CI.

[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.

[hdk10]

@googlebot I signed it!