Validate property allocation size in avifImageCopyProperties()

[jmestwa-coder]

Summary

Add overflow validation before computing the property allocation size in avifImageCopyProperties().

The copy path previously multiplied numProperties by the property size without validating for size_t overflow. Extremely large values could wrap the allocation size and produce an undersized allocation.

This change:

• validates the multiplication before allocation,
• reuses the validated allocation size for initialization,
• and returns AVIF_RESULT_INVALID_ARGUMENT for oversized values.

Test

Add a regression test covering oversized numProperties values.

The test:

• creates a valid property through the public API,
• corrupts only numProperties,
• and verifies avifImageCopy() rejects the malformed state with AVIF_RESULT_INVALID_ARGUMENT.

[wantehchang]

This changes src to an invalid avifImage. (This is why the test has to change src->numProperties back to 1 at line 69 before the destructor of src is called.) This violates the API contract that src points to a valid avifImage.

[wantehchang]

To drive home the necessity of this kind of API contract (whether explicit or implicit), suppose we change this line to the following instead:

    src->numProperties = 2;

It will also make src an invalid avifImage, but the avifImageCopy() function cannot possibly detect this kind of invalid input. So at some point a function has to require that the caller pass a valid input.

[jmestwa-coder]

Thanks for the explanation. My intent with the test was to exercise the overflow check using a malformed object state, but I understand your point that doing so requires violating the invariant that src points to a valid avifImage.

I also see the broader point that changing numProperties to an arbitrary value (whether an extreme value or simply 2) creates an invalid object state that avifImageCopy() cannot generally validate. Given that contract, I can see why this test is not appropriate.

[wantehchang]

This check is not necessary. The API contract requires that srcImage points to a valid avifImage.

[jmestwa-coder]

My reasoning was that the copy path performs an allocation size computation based on a public field, so I viewed the additional check as defensive hardening against malformed object state.

That said, I understand your point that avifImageCopy() operates on a valid avifImage, and that validating this kind of internal invariant violation is outside the API contract. Given that expectation, I can see why this check is considered unnecessary here.