libssl3t64: Issue summary: Use of the low-level GF(2^m) elliptic curve APIs withuntrustedexplicit values for the field polynomial...

Issue summary: Use of the low-level GF(2^m) elliptic curve APIs withuntrustedexplicit values for the field polynomial can lead to out-of-bounds memoryreadsor writes.Impact summary: Out of bound memory writes can lead to an application crashoreven a possibility of a remote code execution, however, in all theprotocolsinvolving Elliptic Curve Cryptography that we're aware of, either only"namedcurves" are supported, or, if explicit curve parameters are supported, theyspecify an X9.62 encoding of binary (GF(2^m)) curves that can't representproblematic input values. Thus the likelihood of existence of a vulnerableapplication is low.In particular, the X9.62 encoding is used for ECC keys in X.509certificates,so problematic inputs cannot occur in the context of processing X.509certificates. Any problematic use-cases would have to be using an "exotic"curve encoding.The affected APIs include: EC_GROUP_new_curve_GF2m(),EC_GROUP_new_from_params(),and various supporting BN_GF2m_*() functions.Applications working with "exotic" explicit binary (GF(2^m)) curveparameters,that make it possible to represent invalid field polynomials with a zeroconstant term, via the above or similar APIs, may terminate abruptly as aresult of reading or writing outside of array bounds. Remote codeexecutioncannot easily be ruled out.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Where it's fixed