fix: guard vector byte-count multiplications against size overflow

[orbisai0security]

Summary

This PR adds overflow checks before computing byte counts for vector memory operations.

Several vector insert/remove paths compute sizes, such as:

• aligned_size * count
• count * vec_aligned_size(vec)
• (vec->length - start - count) * vec_aligned_size(vec)

These values are then passed to MemMove / MemSet. If the multiplication overflows size, the resulting byte count may no longer match the intended logical element count.

This change adds explicit guards before those multiplications, so the operation fails early rather than proceeding with a wrapped size value.

This is intended as defensive robustness / integer-overflow hardening. It is not claiming a demonstrated exploitable vulnerability without a concrete reproducer.

Changes

• Source/Misra/Std/Container/Vec.c

Verification

• Build passes
• Scanner re-scan confirms fix
• LLM code review passed

---

Automated security fix by OrbisAI Security

[brightprogrammer]

While the claim of no overflow check being there is correct, I fail to see why this is a CRITICAL vulnerability. An attached ASAN report + a POC would've been helpful to support your claims.

[orbisai0security]

Thanks, that’s fair feedback. I agree that “CRITICAL” is too strong without a concrete reproducer.

The issue I was trying to address is narrower: several vector operations compute byte counts for MemMove/MemSet as aligned_size * count or similar, without first checking whether the multiplication can overflow size. If very large item_size/alignment/count values are passed to these APIs, the computed byte count can overflow, and the vector’s logical length/capacity arithmetic may no longer correspond to the actual memory operation size.

I should have framed this as defensive integer-overflow hardening rather than a demonstrated critical vulnerability. I'll update the PR title/description accordingly, remove the “critical” wording, and keep the PR scoped as a robustness/MISRA-style bounds check.

Would you be open to reviewing it under that framing?

[brightprogrammer]

Your first few checks have checks placed on count as well, is that not already verified for not being zero?

[orbisai0security]

You’re right, I’ll remove the redundant zero-count checks where the function contract or earlier validation already guarantees that. I only need a non-zero denominator for the overflow expression, but if count is already guaranteed non-zero at that point, the guard can simply be the multiplication-overflow check.

[brightprogrammer]

the (vec->length - start - count) != 0 check is also redundant, MemMove returns early if provided length to move is 0.