GHSA-pffg-92cg-xf5c

### Impact When the exponent is bigger than `r`, the group order of the pairing target group `GT`, the exponentiation à la GLV (`ExpGLV`) can *sometimes* give incorrect results compared to normal exponentiation (`Exp`).

The issue impacts all users using `ExpGLV` for exponentiations in `GT`. This does not impact `Exp` and `ExpCyclotomic` which are sound. Also note that GLV methods in G1 and G2 are sound and _not_ impacted.

### Patches Fix has been implemented in pull request https://github.com/Consensys/gnark-crypto/pull/451 and merged in commit https://github.com/Consensys/gnark-crypto/commit/ec6be1a037f7c496d595c541a8a8d31c47bcfa3d to master branch.

The fix increased the bounds of the sub-scalars by 1. In fact, since https://github.com/Consensys/gnark-crypto/pull/213, we use a fast scalar decomposition that tradeoffs divisions (needed in the Babai rounding) by right-shifts. We precompute `b=2^m*v/d (m > log2(d))` and then at runtime compute `scalar*b/2^m` (`v` is a lattice vector and `d` the lattice determinant). This increases the bounds on sub-scalars by 1 which we check at runtime before increasing the loop size (we don't target constant-timeness). `m` is chosen to be a machine word twice big than `log2(d)` so that we rarely need to increase the loop size. Hence why the issue happens only *sometimes* if we omit to increase the bounds. This bounds increase was implemented in G1 and G2 but forgot in GT.

### Workarounds Updating to `v0.12.1+`. Alternatively, use `Exp` or `ExpCyclotomic` instead. We are not aware of any users using `ExpGLV` anyway.

### References - Fix PR: https://github.com/Consensys/gnark-crypto/pull/451 - Fast scalar decomposition PR: https://github.com/Consensys/gnark-crypto/pull/213 - https://eprint.iacr.org/2015/565 Sec.4.2

### Acknowledgement The vulnerability was reported by [Antonio Sanso](https://github.com/asanso) @ [EF](https://crypto.ethereum.org/).