From: Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Sergey Kaplun <skaplun@tarantool.org>, Sergey Bronnikov <estetus@gmail.com> Cc: tarantool-patches@dev.tarantool.org, max.kokryashkin@gmail.com Subject: Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser (again). Date: Tue, 29 Aug 2023 17:38:34 +0300 [thread overview] Message-ID: <afc73198-143d-5d4c-1a42-81fdf2dcab16@tarantool.org> (raw) In-Reply-To: <ZO308um2V51Y6b6S@root> [-- Attachment #1: Type: text/plain, Size: 4471 bytes --] Hi, Sergey thanks for review! See my comments. New changes were force-pushed. On 8/29/23 16:38, Sergey Kaplun wrote: > Hi, Sergey! > Thanks for the patch! > Please consider my comments below. > > On 29.08.23, Sergey Bronnikov wrote: >> From:sergeyb@tarantool.org >> >> Reported by Sergey Bronnikov. #1054 > I suggest to remove the ticket number, to avoid trouble trouble until > trouble troubles you. :) Agree, removed to avoid troubles. > >> (cherry picked from commit 309fb42b871b6414f53e0e0e708bce0b0d62daff) >> >> The following Lua snippet triggers an out of boundary access to a stack: > Typo: s/an out of boundary/out-of-boundary/ Fixed. > >> ```lua >> a, b, c = 1, 2, 3 >> local d >> for _ in nil do end >> ``` >> >> With execution snippet by LuaJIT instrumented by ASAN it leads to >> a heap-buffer-overflow. > I suppose that it leads ever without ASAN, but the issue is > observable only with ASAN, isn't it? Right. Rephrased it: +-- The test demonstrates a problem with out-of-boundary access +-- to a stack. The problem can be easily observed on execution +-- the sample by LuaJIT by ASAN, sanitizer reports a heap-buffer-overflow. > >> In a function `predict_next` variable `exprpc` looks forward and expects > Minor: I suggest using of `()` for distinguishing function and variable > names. > Feel free to ignore. Fixed. However "function" was before "predict_next". > >> extra bytecodes on the stack. However, `KPRI` is merged to the `KNIL` > Typo: s/the `KNIL`/`KNIL` Fixed. > >> and there is no new bytecode to add, so `exprpc == fs->bclim` and it > Typo: /fs->bclim`/fs->bclim`,/ Fixed. > >> leads to out of boundary access. > Typo: s/out of boundary/out-of-boundary/ Fixed. > > Minor: I suppose that we can mention that the patch fixes the issue via > early return. Added. >> Sergey Bronnikov: >> * added the description and the test for the problem >> >> Part of tarantool/tarantool#8825 >> --- >> >> PR:https://github.com/tarantool/tarantool/pull/9054 >> Branch:https://github.com/tarantool/luajit/tree/ligurio/lj-1054-incorrect-pc-value-predict_next >> Related issue: >> *https://github.com/LuaJIT/LuaJIT/issues/1054 >> >> src/lj_parse.c | 4 +++- >> ...incorrect-pc-value-in-predict_next.test.lua | 18 ++++++++++++++++++ >> 2 files changed, 21 insertions(+), 1 deletion(-) >> create mode 100644 test/tarantool-tests/lj-1054-incorrect-pc-value-in-predict_next.test.lua >> >> diff --git a/src/lj_parse.c b/src/lj_parse.c >> index 343fa797..f1015960 100644 >> --- a/src/lj_parse.c >> +++ b/src/lj_parse.c > <snipped> > >> diff --git a/test/tarantool-tests/lj-1054-incorrect-pc-value-in-predict_next.test.lua b/test/tarantool-tests/lj-1054-incorrect-pc-value-in-predict_next.test.lua >> new file mode 100644 >> index 00000000..17f1b994 >> --- /dev/null >> +++ b/test/tarantool-tests/lj-1054-incorrect-pc-value-in-predict_next.test.lua >> @@ -0,0 +1,18 @@ >> +local tap = require('tap') >> +local test = tap.test('lj-1054-incorrect-pc-value-in-predict_next') >> +test:plan(1) >> + >> + > Excess empty line. Fixed. > >> +-- The test demonstrates a problem with out of boundary access to a stack. > Typo: s/out of boundary/out-of-boundary/ > Comment line width is more than 66 symbols. Fixed. > >> +-- Sample executed in LuaJIT instrumented by ASAN leads to >> +-- a heap-buffer-overflow. > Minor: IDK why, but suggested varian here is "heap buffer overflow". ASAN reports error with hyphens, like this: |==90673==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000fb at pc 0x000108868a95 bp 0x7fff573979a0 sp 0x7fff57397998 READ of size 1 at 0x6020000000fb thread T0| If you don't like variant "heap-buffer-overflow" then we can use variant used in CWE list: "heap-based buffer overflow", see [1]. What variant should 1. https://cwe.mitre.org/data/definitions/122.html > >> +-- See alsohttps://github.com/LuaJIT/LuaJIT/issues/528 > I suggest to add an empty line here. Added. > >> +local lua_code = [[ >> +a, b, c = 1, 2, 3 >> +local d >> +for _ in nil do end >> +]] >> + >> +test:ok(loadstring(lua_code), 'parsing is correct') > I suggest also to test that the behaviour of the executed chunk is the > same as in the PUC RIO Lua 5.1 (like it is done for the lj-1033). Updated: TAP version 13 1..3 ok - chunk loaded successfully ok - loaded function is failed (expected) ok - correct error message > >> + >> +test:done(true) >> -- >> 2.34.1 >> [-- Attachment #2: Type: text/html, Size: 14567 bytes --]
next prev parent reply other threads:[~2023-08-29 14:38 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-29 10:42 Sergey Bronnikov via Tarantool-patches 2023-08-29 13:38 ` Sergey Kaplun via Tarantool-patches 2023-08-29 14:38 ` Sergey Bronnikov via Tarantool-patches [this message] 2023-08-29 14:43 ` Sergey Kaplun via Tarantool-patches 2023-08-29 15:11 ` Sergey Bronnikov via Tarantool-patches 2023-08-30 10:53 ` Maxim Kokryashkin via Tarantool-patches 2023-08-31 11:48 ` Sergey Bronnikov via Tarantool-patches 2023-09-27 12:33 ` Igor Munkin via Tarantool-patches
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=afc73198-143d-5d4c-1a42-81fdf2dcab16@tarantool.org \ --to=tarantool-patches@dev.tarantool.org \ --cc=estetus@gmail.com \ --cc=max.kokryashkin@gmail.com \ --cc=sergeyb@tarantool.org \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser (again).' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox