The bug isn't actually the copy but the bounds check.

If you had a dynamically sized heap allocated buffer as the destination you'd still have a denial of service attack, no matter what language was used.

The actual vulnerability is indeed the copy. What we used to do is this:

1. Find out how big this data is, we tell the ASN.1 code how big it's allowed to be, but since we're not storing it anywhere those tests don't matter

2. Check we found at least some data, zero isn't OK, failure isn't OK, but too big is fine

3. Copy the too big data onto a local buffer

The API design is typical of C and has the effect of encouraging this mistake

    int ossl_asn1_type_get_octetstring_int(const ASN1_TYPE *a, long *num, unsigned char *data, int max_len)

This encourages people to either forget the return value entirely (it's just some integer, who cares, in the happy path this works) or check it for -1 which indicates some fatal ASN.1 layer problem, give up, but ignore other values.

If the thing you got back from your function was a Result type you'd know that this wasn't OK, because it isn't OK. But the "Eh, everything is an integer" model popular in C discourages such sensible choices because they were harder to implement decades ago.

Assuming you're talking about a heap buffer overrun, it's still possible to exploit for EoP in some cases.

A denial of service attack is a million times better than an RCE attack.