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 9C665E3F09B; Mon, 8 Jul 2024 15:27:50 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9C665E3F09B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1720441670; bh=w9cvVH2ahuqUB81s/JFcj8qLuAFafAC3/Ox2fGPMgQk=; h=To:Date:In-Reply-To:References:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=U2OmomWajQ3QH/2mDnqddxYYnOGjxXhr1qJXaJRNkKCzqL0OEuGBFcwjJrR5UqYLh ANzV5TAMUgOE2T/6A8zGlNAkFEgBeL+ZpiOoeC5dNOMkeJepRiGdnmJ5aT46hRno+p vDwZ7grgTBA0hNQ4iWHNmxMWWGhTMtjGtixFADbI= Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 43DB2E3F09B for ; Mon, 8 Jul 2024 15:27:38 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 43DB2E3F09B Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-52e99060b0dso4238734e87.1 for ; Mon, 08 Jul 2024 05:27:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720441657; x=1721046457; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vU0t5qWczrF3v5E9AHpZCp3Khh8tDFoVlXLwPWdJvWg=; b=WlqwZykkVAwf98b3ONtCBZUtPp8GC3UCT53lZ9AHGzObVrsp3gbMksk39DoiImbaTz mNadKcmZzRLykxjysLGfPcrr/oXoCW5xfZueATeKWqrQxmoJMgJhgJY1KqzAKal02UEN toV3J/cWD79taCmwLFlzhWiNY2TtjjdL1ZQOuNZX8l5np5XlqwlZ/zH89sDScv31Qyfu IHDM3ZUuonAebdLC2ru3pmHlaDQ4Yhb+Z2UQ21uQeRh2SFMg9DB3FE66Lunz2Cmfl/Rm K1AGlIO6itsGc3RNS1VPols3ETtBw5AiHq1hABQj73hKZSOg1yXuVQWiMx437RfYTK1J ph7A== X-Gm-Message-State: AOJu0YzuhCJYdBiEZOb8WI3v0RhmVtYaGSK+3GCjknSkQA9tNtIdIxOS BPz30mypOhREMD+J4vb8Gv6fCd1HF6XSiwmIq2JWt5QMf72sFc/lx4uPssB2 X-Google-Smtp-Source: AGHT+IEMM52BXLIlC+B3koD9IgNm+glDYwO6MxV2bPWKm0AoC43m2p9aDlXPRq0e4HJq/jfq10xU9Q== X-Received: by 2002:a05:6512:20d1:b0:52e:96d7:2f3a with SMTP id 2adb3069b0e04-52ea06f7c10mr7596848e87.58.1720441657213; Mon, 08 Jul 2024 05:27:37 -0700 (PDT) Received: from pony.mail.msk ([5.181.62.98]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52eab036662sm603876e87.4.2024.07.08.05.27.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jul 2024 05:27:36 -0700 (PDT) To: tarantool-patches@dev.tarantool.org, Sergey Kaplun , Maxim Kokryashkin Date: Mon, 8 Jul 2024 15:26:13 +0300 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [Tarantool-patches] [PATCH luajit 1/2] FFI: Treat cdata finalizer table as a GC root. 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" From: Mike Pall Thanks to Sergey Bronnikov. (cherry picked from commit dda1ac273ad946387088d91039a8ae319359903d) There is a table `CTState->finalizer` that contains cdata finalizers. This table is created on initialization of the `ffi` module by calling the functions `luaopen_ffi` and `ffi_finalizer`. In some circumstances, this table could be collected by GC and then accessed by the function `lj_gc_finalize_cdata`. This leads to a heap-use-after-free problem. The patch fixes the problem. Sergey Bronnikov: * added the description and the tests for the problem Part of tarantool/tarantool#10199 --- src/lj_gc.c | 3 + ...free-on-access-to-CTState-finalizer.test.c | 105 ++++++++++++++++++ ...ee-on-access-to-CTState-finalizer.test.lua | 18 +++ 3 files changed, 126 insertions(+) create mode 100644 test/tarantool-c-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.c create mode 100644 test/tarantool-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.lua diff --git a/src/lj_gc.c b/src/lj_gc.c index 591862b3..42348a34 100644 --- a/src/lj_gc.c +++ b/src/lj_gc.c @@ -99,6 +99,9 @@ static void gc_mark_start(global_State *g) gc_markobj(g, tabref(mainthread(g)->env)); gc_marktv(g, &g->registrytv); gc_mark_gcroot(g); +#if LJ_HASFFI + if (ctype_ctsG(g)) gc_markobj(g, ctype_ctsG(g)->finalizer); +#endif g->gc.state = GCSpropagate; } diff --git a/test/tarantool-c-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.c b/test/tarantool-c-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.c new file mode 100644 index 00000000..ad2d8e62 --- /dev/null +++ b/test/tarantool-c-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.c @@ -0,0 +1,105 @@ +#include + +#include "lua.h" +#include "lauxlib.h" + +#include "test.h" + +/* + * This test demonstrates LuaJIT's incorrect behaviour on + * loading Lua chunk. + * See https://github.com/LuaJIT/LuaJIT/issues/1168 for details. + * + * The GC is driving forward during parsing of the Lua chunk (`chunk`). + * The chunk contains plenty of global objects, and the parsing + * of this creates a lot of strings to be used as keys in `_G`. + * Also, it contains several imaginary numbers (1i, 4i, 8i). + * That leads to the opening of the FFI library on-demand during the + * parsing of these numbers. After the FFI library is open, `ffi.gc` + * has the finalizer table as its environment. But, there is no + * FFI module table anywhere to anchor the `ffi.gc` itself, and + * the `lua_State` object was marked before the function is + * placed on it. Hence, after the atomic phase, the table + * is considered dead and collected. Since the table is collected, + * the usage of its nodes in the `lj_gc_finalize_cdata` leads + * to heap-use-after-free. + * + * The second reason when the loaded function/chunk isn't loaded + * on the `lua_State`, so the cdata (or the FFI module table) + * isn't marked is when the chunk contains an error (the chunk + * below is valid grammatically but not semantically). + * + * The repro itself is very fragile, since if we add any of the + * `luaopen_*()` or `luaL_openlibs()` calls, it may cause + * the marking of the `lua_State *` at the moment when the + * FFI module table is on it, so the ffi.gc function and + * finalizer table are marked. + */ + +char chunk[] = +"a=b\n" +"Y{d^v,vy^y{\n" +" K/false*#4,o,v,oo,v,Lv8,v,L,v,o5,o,v,oo,v,Lv8,v,Lv8,v,oee,vL,8,vv8,v,o,v,oo,v,Lv4,v,L8,o,v,oo,v,Lv4,v,Lv8,v,o9,o,v,oo,v,Lv8,v,Lv8,v,o,Io,v1,v,oo,v,vL,8,vv8,v;N3%0,yzx{\n" +" 0,x{0,3,D,3;0,yzx{3;uyyyyzx{0,3;3,yzx{\n" +" 0,0,y9,o,v,oo,v,Lv4,v,Lv8,v,oeeeey8,v,oeeeeyv,o,v,oo,v,Lv8,v,Lv8,v,oeeeeyv,o,v,oo,v,Lv8,v,Lv4,v,Lv8,v,oeeeeyv,o,v,oo,v,Lv8,v,Lv8,v,o9,eee,oo,voyyy,v,oo,v,oo,voyyy,v,oo,v,vL,8,v,v^I{\n" +" K,v,oo,v,vL,8,vv8,v8,v,Lv8,v,o,oo,vy,eeee,oo,v,v,oo,v,vL,8,vv8,vy^yI{\n" +" K,v,oo,v,vL,5/4>4*#4/4/4>4*#8i*#4/4/4>4*#4/4/4>6*#4.4>4/4>4*#1i*#4/4/4>46*#4/6/444446*#4i*#45/46/4>44444*#44444454444/49/4>410*#444484445/48,v,oe,ee,oo,vy,v,oo,v,e1,oo,vy,v,oo,v,vL,8,vv8,v7^y8,o,v,oo,v,Lv4,v,Le{\n" +" K,v,o0,o,v,oo,v,Lv8,v,Lv8,vK=A{44;4,4,oy^y{Ky,3,y{z{3,y{3;z{3%0,y{0,3;z{\n" +" 3%0,y3;3%0,yz<{3;zx{3;3%0,yzx{3;zx{0,3,DOJv0,3%0,yzx{y8{\n" +" 3%0,y{y3;3,y{0,3;z{0,3;3,y{3;z{0,3,0,3;3,y{\n" +" zx{0,3;3,yzx{3;zx{0,3;3,yzx{0;N3%0,yzx{0,x{0,3,D,3;3%0,yzx{\n" +" 3;ux{3,yzx{0,y{3;3%0,yzx{y,Io,v,v,oo,v,vL,8,vv8,v;N3%0,yzx{0,x{D,3;3%0,yzx{\n" +" 3;u{3;1%0,yzx{\n" +" y,o,v,oo,v,Lv4,v,Lv8,v,o,v,o,o,v,oo,v,L,v,L,v,o,o,v,o,v,L,v,L,v,L,v,o,o,v,o,v,L,v,L,v,o,e,o,v,v,o,v,e,oo,v,v,oo,v,vL,8,v,v7y^y{\n" +" K8,v,oo,v,vL,vv8,v8,v,Lv8,v,o0,oo,v,v,oo,v,vL,v,o,v,o,v,L,v,Lv8,v,o,v,o,o,v,oo,v,Lv8,v,L1,v,ov,o,v,oo,v,Lv8,v,Lv4,v,Lv8,v,oeeeeyv,o,v,oo,v,Lv8,v,Lv8,v,o,e,oo,vy,v,oo,v,e,o,v,v,o,v,vL,8,v8,vy^y{\n" +" K4,v,oo,v,vL,vv8,vee8,v,Lv8,v,o9,oo,voyyy,v,oo,v,vL,8,vv8,v9y^yI{\n" +" K7,v,oo,v,vL,8,vvv,v3,v,oe1,o,v\n" +" }\n" +" }\n" +" }\n" +" }}\n" +" }}}\n" +" }}}}\n" +" }}}}}}}\n" +" }}}}}}\n" +" }}}}}}\n" +" }}}}}}}}\n" +" }\n" +" }\n" +" }\n" +" }}}}\n" +" }\n" +"}}\n" +"\n" +"}\n"; + +/* + * lua_close is a part of testcase, so testcase creates + * it's own Lua state and closes it at the end. + */ +static int lua_cdata_finalizers_testcase_part_1(void *test_state) +{ + /* Shared Lua state is not needed. */ + (void)test_state; + + /* Setup. */ + lua_State *L = luaL_newstate(); + + luaL_loadbufferx(L, chunk, sizeof(chunk), "test", "t"); + + /* Teardown. */ + lua_settop(L, 0); + lua_close(L); + + return TEST_EXIT_SUCCESS; +} + +int main(void) +{ + const struct test_unit tgroup[] = { + test_unit_def(lua_cdata_finalizers_testcase_part_1), + }; + const int test_result = test_run_group(tgroup, NULL); + + return test_result; +} diff --git a/test/tarantool-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.lua b/test/tarantool-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.lua new file mode 100644 index 00000000..fca5ec76 --- /dev/null +++ b/test/tarantool-tests/lj-1168-heap-use-after-free-on-access-to-CTState-finalizer.test.lua @@ -0,0 +1,18 @@ +local tap = require('tap') + +-- This test demonstrates LuaJIT's heap-use-after-free +-- on collecting garbage. Test simulates "unloading" of the library, +-- or removing some of the functionality of it and then calls +-- `collectgarbage`. +-- See https://github.com/LuaJIT/LuaJIT/issues/1168 for details. +local test = tap.test('lj-1168-heap-use-after-free-on-access-to-CTState-finalizer') +test:plan(1) + +local ffi = require('ffi') + +ffi.gc = nil +collectgarbage() + +test:ok(true, 'no heap use after free') + +test:done(true) -- 2.34.1