From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 9D7195D305B; Thu, 31 Aug 2023 14:48:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9D7195D305B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1693482484; bh=5f/yIVoqayOC/G30v8bKxA1beDlNWCSo7UTULdU8bsA=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=G0tgq1+KJFoDecGeXZPlAl0JARmXtsw1N0kehokyus2Gix5VXtq4WRXNOg6UH3MZv RGeYogbdGg3LSAeULCiBAfnnMwQ6n2iDbq6JEYDuQPZE2TiQqQFt/vXA4Vyd089/M+ Z/5iRytIfKrosd1RHmNjjMvHTxaffqZV2hy+Fh8E= Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [95.163.41.79]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 1E9215CE0FB for ; Thu, 31 Aug 2023 14:48:02 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 1E9215CE0FB Received: by smtp38.i.mail.ru with esmtpa (envelope-from ) id 1qbg9Y-005EEi-2r; Thu, 31 Aug 2023 14:48:01 +0300 Message-ID: Date: Thu, 31 Aug 2023 14:48:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: Maxim Kokryashkin , Sergey Bronnikov Cc: max.kokryashkin@gmail.com, tarantool-patches@dev.tarantool.org References: <8b2d744f68eb138c2b2c37e1ac851181e303b485.1693305720.git.sergeyb@tarantool.org> <6cus2hpqotdwax3q66xznqgnkekikkhc6ndd47gyc76ki2v5qt@oyjw5ucvzhrd> In-Reply-To: <6cus2hpqotdwax3q66xznqgnkekikkhc6ndd47gyc76ki2v5qt@oyjw5ucvzhrd> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD96E142CFC92DB15CD90AAA51E9363FBE6A21DF977184D824F182A05F5380850409FE8DBA6AA02A38EB3F8D0F5DB1277CC429CA975104148B05FF0BAE677C83EAE X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE76574C3D62D66A535EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F790063725FA9CD6081C82518638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D81AE0F182A73623576470C59687D902EF117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC09CDF8F23AD6196DA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE9647ADFADE5905B12AE38A8E97BAFFB1D8FC6C240DEA76429C9F4D5AE37F343AA9539A8B242431040A6AB1C7CE11FEE34E7D9683544204AF2D242C3BD2E3F4C6C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407978DA827A17800CE773BC869C69ECC1572DBA43225CD8A89F616AD31D0D18CD5C35872C767BF85DA2F004C90652538430E4A6367B16DE6309 X-B7AD71C0: 1B70FBA5C9BEEE72C9761FC34675ADEB871C96603B655635EE9D5CB6078CC77C615B457267FD5C5C0D10BAB907AB3466 X-C1DE0DAB: 0D63561A33F958A526D5D07B53982597E3D14A468E192DB762F2D3617429C4BFF87CCE6106E1FC07E67D4AC08A07B9B062B3BD3CC35DA588CB5012B2E24CD356 X-C8649E89: 1C3962B70DF3F0ADBF74143AD284FC71106E36FF2641B7B8424CF958EAFF5D571004E42C50DC4CA955A7F0CF078B5EC49A30900B95165D344888A9AABCDD3225CB9169A10D446D50DAEA61E0B32A59271AC17F0447E7306DFA7EAA831CD52C391D7E09C32AA3244CB2DC454EB5DCB636D1AAC6CF1D1935953A76366E8A9DE7CABAD658CF5C8AB4025DA084F8E80FEBD3FFA33E6B6B2F82C47A83BD0C44CE203720ABEDE4BBDD9CDD X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj6jqRMsEo8wdZE/qsVieIXw== X-Mailru-Sender: 11C2EC085EDE56FAC07928AF2646A7698A2850B4C46816BAB3F8D0F5DB1277CCFA95C477BC5130F8EBA65886582A37BD66FEC6BF5C9C28D98A98C1125256619760D574B6FC815AB872D6B4FCE48DF648AE208404248635DF X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit] Fix predict_next() in parser (again). X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Bronnikov via Tarantool-patches Reply-To: Sergey Bronnikov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Max thanks for review! See my answers. Updated branch force-pushed. Sergey On 8/30/23 13:53, Maxim Kokryashkin via Tarantool-patches wrote: > Hi, Sergey! > Thanks for the patch! > LGTM, except for a few nits below. > On Tue, Aug 29, 2023 at 01:42:40PM +0300, Sergey Bronnikov via Tarantool-patches wrote: >> From: sergeyb@tarantool.org >> >> Reported by Sergey Bronnikov. #1054 >> >> (cherry picked from commit 309fb42b871b6414f53e0e0e708bce0b0d62daff) >> >> The following Lua snippet triggers an out of boundary access to a stack: >> >> ```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 suggest the following rephrasing with grammar fixes: > | During the execution of this snippet with LuaJIT instrumented by ASAN, > | it leads to a heap buffer overflow. Updated, but replaced "heap buffer overflow" with "heap buffer overflow" (same wording is used in CWE [1]). 1. https://cwe.mitre.org/data/definitions/122.html >> In a function `predict_next` variable `exprpc` looks forward and expects > Typo: s/In a/In/ Fixed. >> extra bytecodes on the stack. However, `KPRI` is merged to the `KNIL` > Typo: s/to the/to/ Fixed. >> and there is no new bytecode to add, so `exprpc == fs->bclim` and it >> leads to out of boundary access. > The last sentence that you don't have here, but have on GitHub should look like > the following: > | The issue has been fixed by an early return when `pc >= fs->bclim`. Fixed. >> 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 >> @@ -2511,9 +2511,11 @@ static void parse_for_num(LexState *ls, GCstr *varname, BCLine line) >> */ >> static int predict_next(LexState *ls, FuncState *fs, BCPos pc) >> { >> - BCIns ins = fs->bcbase[pc].ins; >> + BCIns ins; >> GCstr *name; >> cTValue *o; >> + if (pc >= fs->bclim) return 0; >> + ins = fs->bcbase[pc].ins; >> switch (bc_op(ins)) { >> case BC_MOV: >> name = gco2str(gcref(var_get(ls, fs, bc_d(ins)).name)); >> 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) >> + >> + >> +-- The test demonstrates a problem with out of boundary access to a stack. >> +-- Sample executed in LuaJIT instrumented by ASAN leads to >> +-- a heap-buffer-overflow. >> +-- See also https://github.com/LuaJIT/LuaJIT/issues/528 > This chunk is a bit dated and I don't really want to bother with > going through a bunch of emails and sequential diffs, so I'll just > bring the actual one here by myself. > > Here it is: > -- 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 > Typo: s/execution/execution of/ > Typo: s/sanitizer/where the sanitizer/ > -- reports a heap-based buffer overflow. > -- See also https://github.com/LuaJIT/LuaJIT/issues/1054. > > Otherwise, considering the changes you've already made after > Sergey's comments, this part is ok. Updated comment: --- a/test/tarantool-tests/lj-1054-fix-incorrect-pc-value-in-predict_next.test.lua +++ b/test/tarantool-tests/lj-1054-fix-incorrect-pc-value-in-predict_next.test.lua @@ -4,8 +4,8 @@ test:plan(3)  -- 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-based buffer overflow. +-- on execution of the sample by LuaJIT instrumented by ASAN, +-- where the sanitizer reports a heap-based buffer overflow.  -- See also https://github.com/LuaJIT/LuaJIT/issues/1054.  local res_f = loadstring([[ >> +local lua_code = [[ >> +a, b, c = 1, 2, 3 >> +local d >> +for _ in nil do end >> +]] >> + >> +test:ok(loadstring(lua_code), 'parsing is correct') >> + >> +test:done(true) >> -- >> 2.34.1 >>