[hakarrr]

Fixes: #561

The existing #507 flexi-parser vector still reports an error when the UTF8 fix is removed, because parsing fails later for an unrelated reason. Add a direct der_decode_utf8_string() regression so that failure cannot hide acceptance of an invalid leading continuation byte.

The test checks all leading bytes from 0x80 through 0xbf, each followed by another continuation byte, and also checks the original bf bf UTF8 payload. The DER length and output buffer are sufficient for the old decoder to accept the pair, so the expected CRYPT_INVALID_PACKET tests the invalid leading byte rather than truncation or output capacity. The existing flexi-parser vector stays unchanged. No production code changes.

Validation on Linux with LibTomMath:

• Native -Werror full suite: 30 passed, 0 failed, 1 nop.
• ASan + UBSan full suite with leak detection: 30 passed, 0 failed, 1 nop; no sanitizer findings. The linked LibTomMath static library was not sanitizer-instrumented.
• Mutation check: manually removing the two UTF8 guards shown in test for issue #507 always passes #561 leaves the old DER suite green, but fails the new test at the first continuation-byte assertion. Restoring the decoder makes it pass.

This adds coverage for the UTF8 portion of #507. It does not change the flexi-parser underflow handling discussed in #561.

Checklist

• tests are added or updated
• added a Fixes: tag to the commit message

[hakarrr]

Could a maintainer review this direct DER regression coverage for invalid UTF-8 leading continuation bytes? Please let me know if the cases need changing or if anything else is needed before it can move forward. Thanks.