don't create oversize bignums in binary matching

Bignums are artifically restricted in size.  Arithmetic and logical
operations check the sizes of resulting bignums, and turn oversize
results into system_limit exceptions.

However, this check is not performed when bignums are constructed by
binary matching.  The consequence is that such matchings can construct
oversize bignums that satisfy is_integer/1 yet don't work.  Performing
arithmetic such as Term - 0 fails with a system_limit exception.  Worse,
performing a logical operation such as Term band Term results in [].
The latter occurs because the size checking (e.g. in erts_band()) is
a simple ASSERT(is_not_nil(...)) on the result of the bignum operation,
which internally is [] (NIL) in the case of oversize results.  However,
ASSERT is a no-op in release builds, so the error goes unnoticed and []
is returned as the result of the band/2.

This patch addresses this by preventing oversize bignums from entering
the VM via binary matching:

- the internal bytes_to_big() procedure is augmented to return NIL for
  oversize results, just like big_norm()
- callers of bytes_to_big() are augmented to check for NIL returns and
  signal errors in those cases
- erts_bs_get_integer_2() can only fail with badmatch, so that is the
  Erlang-level result of oversize bignums from binary matches
- big_SUITE.erl is extended with a test case that fails without this
  fix (no error signalled) and passes with it (badmatch occurs)

Credit goes to Nico Kruber for the initial bug report.

1 files changed, 2 insertions, 0 deletions

diff --git a/erts/emulator/beam/big.c b/erts/emulator/beam/big.c
index de7d370938..d1e46e3063 100644
--- a/erts/emulator/beam/big.c
+++ b/erts/emulator/beam/big.c
@@ -1900,6 +1900,8 @@ Eterm bytes_to_big(byte *xp, dsize_t xsz, int xsgn, Eterm *r)
 	*rwp = d;
 	rwp++;
     }
+    if (rsz > BIG_ARITY_MAX)
+	return NIL;
     if (xsgn) {
       *r = make_neg_bignum_header(rsz);
     }