fix stack out-of-bounds read in core cluster heuristic

[soma0212]

cluster_processors[3] is indexed by a counter that nothing bounds:

• the table is sized from usable_processors, which cpuinfo_arm_linux_init passes as valid_processors (VALID flag and listed in /proc/cpuinfo), while both loops start a new cluster for every processor carrying just CPUINFO_LINUX_FLAG_VALID
• the two counts diverge whenever a CPU is in the possible and present lists but absent from /proc/cpuinfo, which init.c already calls fairly common for offline cores
• 12 present CPUs with 10 listed in /proc/cpuinfo puts the 11th at cluster Request a release #3 and reads cluster_processors[3]; the 5/6/8 tables never write entry [2] either, so those run into uninitialized stack first
• guarding only the verification pass is deliberate, since the assignment pass walks the same processors in the same order, and returning false from there would leave package_leader_id half rewritten, which this function documents it never does

Exhausting the table now fails the heuristic, so the caller falls back to the sequential scan the way it already does for every other mismatch.

[meta-cla]

Hi @soma0212!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!