Hi Guilhem, On Fri, Jun 23, 2023 at 12:27:32PM +0200, Guilhem Moulin wrote: > On Thu, 22 Jun 2023 at 18:08:39 +0200, Guilhem Moulin wrote: > > bullseye > > ======== > > > > $ lua5.1 ./cstack.lua > > testing stack overflow detection > > nesting coroutines running after recoverable errors > > final count: 198 > > > > $ lua5.2 ./cstack.lua > > testing stack overflow detection > > nesting coroutines running after recoverable errors > > final count: 197 > > > > $ lua5.3 ./cstack.lua > > testing stack overflow detection > > nesting coroutines running after recoverable errors > > final count: 197 > > > > $ lua5.4 ./cstack.lua > > testing stack overflow detection > > nesting coroutines running after recoverable errors > > E: Child terminated by signal ‘Segmentation fault’ > > One more thing: cstack.lua attached earlier contains the unit test upstream > added to > v5.4.4 in > https://github.com/lua/lua/commit/74d99057a5146755e737c479850f87fd0e3b6868 . > > crash.lua from http://lua-users.org/lists/lua-l/2021-10/msg00123.html > yields the same result: only bullseye's lua5.4=5.4.2-2 results in a crash. > All other versions error out in a (controlled) stack overflow as > intended (like for example1.lua and example2.lua). > > > AFAICT lua5.3 is unaffected since there L->nCcalls is incremented in > > lua_resume() i.e., outside LUAI_THROW: > > https://sources.debian.org/src/lua5.3/5.3.3-1.1/src/ldo.c/#L659 > > > > Didn't try to bisect but I believe this was introduced upstream at > > https://github.com/lua/lua/commit/287b302acb8d925178e9edb800f0a8d18c7d35f6#diff-a1e6f0be3689739fa1e5707427e78d792c7f6a333bed95fd05c4382d60bda7c4L687-R689 > > Tried to build released versions from lua-all.tar.gz meanwhile (in a > bullseye chroot), I was indeed only able to reproduce this in 5.4.2 and > 5.4.3 (the above 287b302a was added between 5.4.1 and 5.4.2). > > version crash.lua > ------- --------- > 5.0 SIGSEGV > 5.0.1 SIGSEGV > 5.0.2 SIGSEGV > 5.0.3 SIGSEGV > 5.1 SIGSEGV > 5.1.1 SIGSEGV > 5.1.2 SIGSEGV > 5.1.3 success > 5.1.4 success > 5.1.5 success > 5.2.0 SIGSEGV > 5.2.1 success > 5.2.2 success > 5.2.3 success > 5.2.4 success > 5.3.0 success > 5.3.1 success > 5.3.2 success > 5.3.3 success > 5.3.4 success > 5.3.5 success > 5.3.6 success > 5.4.0 success > 5.4.1 success > 5.4.2 SIGSEGV > 5.4.3 SIGSEGV > 5.4.4 success > 5.4.5 success > 5.4.6 success > > All releases in 5.3.x pass the test. 5.0 releases, as well as early 5.1 > releases, and 5.2.0, do segfault, but I believe the reason is > unrelated and was documented at https://www.lua.org/bugs.html#5.1.2-4 > resp. https://www.lua.org/bugs.html#5.2.0-4. Either way the test passes > on bullseye's lua5.1=5.1.5-8.1+b3, lua5.2=5.2.4-1.1+b3, and > lua5.3=5.3.3-1.1+b1. > > I didn't adjust affected versions CVE/list so the Security Team can make > their own assessment (also buster and bullseye have the same version and > AFAIK it's not possible to mark only one release as <not-affected>).
thanks for the analysis. I want to point out that it's really important to not rely on the POC for making the not-affected assessment (and when not confirmed, rather err on the safe side and keep something marked affected). Your analysis at first glance seems to make sense, but to be on safe side, unless jmm seems it to fit, I would rather go with the still affected, but ignored for stable and older suites. If you can prod upstream to double-check with them if you have indeed found the introducing commit, then we can update the CVE entry accordingly. Regards, Salvatore
