Fix an off-by-one bug in BN_GF2m_poly2arr(3).
authorschwarze <schwarze@openbsd.org>
Sun, 20 Nov 2022 22:23:43 +0000 (22:23 +0000)
committerschwarze <schwarze@openbsd.org>
Sun, 20 Nov 2022 22:23:43 +0000 (22:23 +0000)
commit0334e08b415550dd4e3ca9f961ff47ffdb00dc26
tree1190a91ed679faacdb813d807c326a2b33fc8632
parent48308923a9e2f329c111bc953b95b827ef69f683
Fix an off-by-one bug in BN_GF2m_poly2arr(3).

If the last argument, the size of the output array, is too small to
contain all degrees present in the input polynomial plus one for the
terminating -1, the function is documented to return the size of the
output array that would be needed (in comments in the source code, in
the new manual page, and by the way how the function is used by other
functions in the same file).  However, in case of overflow, the existing
code failed to include the element needed for the terminating -1 in the
return value, wrongly indicating success if everything but the -1 did
fit and reporting failure with a size that was still too small otherwise.

According to tb@, this is very unlikely to cause vulnerabilities in
practical applications because there is no real reason to pick a
reducing polynomial longer than a pentanomial, because all known
callers use either fixed size arrays of size 6 or dynamic allocation,
because use of GF(2^m) is rare in practice, and GF(2^m) with custom
reducing polynomials even more so.

OK tb@
lib/libcrypto/bn/bn_gf2m.c