[0014] CRASH detected in lj_ir_kgc due to a fault at or near 0x00007ff7f3274008 leading to SIGSEGV

[pwnhacker0x18]

poc.txt

[Buristan]

The reason is the uint32_t underflow in J->irbotlim due to irbuf shifting up. This happens when the shift size is greater than J->irbotlim. Hence, irbufptr points to the middle of the buffer, and J->irbotlim has the "negative" offset.

(gdb) p szins >> 2
$2 = 16384
(gdb) p J->irbotlim
$3 = 15496
# And after the subtraction the limit overflows.
(gdb) p J->irbotlim
$4 = 4294966408

The dirty patch masks the issue, but obviously there should be a better way to fix it.

diff --git a/src/lj_ir.c b/src/lj_ir.c
index 9a51186f..f1b9db10 100644
--- a/src/lj_ir.c
+++ b/src/lj_ir.c
@@ -93,7 +93,7 @@ static void lj_ir_growbot(jit_State *J)
   lj_assertJ(szins != 0, "zero IR size");
   lj_assertJ(J->cur.nk == J->irbotlim || J->cur.nk-1 == J->irbotlim,
              "unexpected IR growth");
-  if (J->cur.nins + (szins >> 1) < J->irtoplim) {
+  if (J->cur.nins + (szins >> 1) < J->irtoplim && (szins >> 2) <= J->irbotlim) {
     /* More than half of the buffer is free on top: shift up by a quarter. */
     MSize ofs = szins >> 2;
     memmove(baseir + ofs, baseir, (J->cur.nins - J->irbotlim)*sizeof(IRIns));

[MikePall]

The IR should never grow to that point, since there are limit checks at strategic points. However compiling string.format may lead to an unlimited expansion of the IR.

I've added a (reasonable) limit. Thanks!

Simplified testcase:

local fmt = ("%"):rep(50000)
for i=1,100 do s = fmt:format() end