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 E09216AD888; Wed, 25 Oct 2023 10:48:11 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org E09216AD888 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1698220092; bh=67os8tvo9ZLYjHdcKquqk4R729m3HF9K8BUdbDeIOM8=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=VUMpw19lj3IWYfN0FeEmEwL+rJ+QEr8DM81Ps0EjLRxh9NAw+yB+NIC3xF8ltqLnX k5Grbm0GTEOoFHtV64fmFlZoDgwPbkQG7knYVdm7res8c+x1LUSG3fNQ8YSoLe5b77 fRXBLH+6rXeWVx4aQpP1kLt9Huj6gif348a4NOVg= Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [95.163.41.83]) (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 DE91469467E for ; Wed, 25 Oct 2023 10:48:10 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org DE91469467E Received: by smtp45.i.mail.ru with esmtpa (envelope-from ) id 1qvYcb-004pfQ-1k; Wed, 25 Oct 2023 10:48:10 +0300 Date: Wed, 25 Oct 2023 10:48:09 +0300 To: Sergey Kaplun Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD9315D6E1B1B5C3D6DC232CB6F24005D11807874EA19E1CCF400894C459B0CD1B9CF0D0BDB9F9F49D9AFB8265869A37E3F6B0664DCB27AD11C4A9DBE0811142006 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7E50EC9128971FD6EEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637DD7A7F9003AF293F8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8BEB517A3BB995216D6AF321CD53CCACA117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE140C956E756FBB7A452896749CDDA0A6D8FC6C240DEA76429C9F4D5AE37F343AA9539A8B242431040A6AB1C7CE11FEE32A336C651863509103F1AB874ED89028C4224003CC836476E2F48590F00D11D6E2021AF6380DFAD1A18204E546F3947CD2DCF9CF1F528DBC2E808ACE2090B5E1725E5C173C3A84C3C5EA940A35A165FF2DBA43225CD8A89F83C798A30B85E16BCE5475246E174218B5C8C57E37DE458BEDA766A37F9254B7 X-C1DE0DAB: 0D63561A33F958A589401E7C3B28FEA2DE7BCB7C444E1733F7E3AA8BA35D5F5FF87CCE6106E1FC07E67D4AC08A07B9B0A6C7FFFE744CA7FBCB5012B2E24CD356 X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF07F45A71EFE27324941FF35283204B4E3E0DACB3C05AAD0AE3C46D71EE73DC7BF49F51687F14C9B8A789783558ABFE9CB73859E2F30AECBA662E55CC37F2A55AE48CAC7CA610320002C26D483E81D6BE64ACE4A408B72B61B0CA6F94E606A667A52EF62A646584F811BD90D3D42C882D43082AE146A756F3 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj7UiV2qa299oY6CEn6PxThw== X-Mailru-Sender: 7940E2A4EB16C997FE3FA4BCD65AE2C9CF0D0BDB9F9F49D9AFB8265869A37E3FE2527C969975515CFF9FCECFB8D89CB6C77752E0C033A69E235A20A81F3B0E39AB3C5F247CB2F7F93A5DB60FBEB33A8A0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 4/6] FFI: Fix dangling reference to CType. 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: Maxim Kokryashkin via Tarantool-patches Reply-To: Maxim Kokryashkin Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hi, Sergey! Thanks for the patch! Please consider my comments below. On Mon, Oct 23, 2023 at 12:22:04PM +0300, Sergey Kaplun wrote: > From: Mike Pall > > (cherry-picked from commit ae533e3a6c009b5df79b11cd5787d249202fa69c) > > During the conversion of a cdata function object to some cdata value in > `lj_cconv_ct_tv()`, reallocation of `cts->tab` in `lj_ctype_intern()` > may occur. In that case, the reference to the `CType` object becomes > invalid. This patch saves the `CTypeID` of the given function and gets > its `CType` again after possible reallocation. > > Sergey Kaplun: > * added the description and the test for the problem > > Part of tarantool/tarantool#9145 > --- > src/lj_cconv.c | 2 + > .../fix-dangling-reference-to-ctype.test.lua | 59 +++++++++++++++++++ > 2 files changed, 61 insertions(+) > create mode 100644 test/tarantool-tests/fix-dangling-reference-to-ctype.test.lua > > diff --git a/src/lj_cconv.c b/src/lj_cconv.c > index 37c88852..94ca93bb 100644 > --- a/src/lj_cconv.c > +++ b/src/lj_cconv.c > diff --git a/test/tarantool-tests/fix-dangling-reference-to-ctype.test.lua b/test/tarantool-tests/fix-dangling-reference-to-ctype.test.lua > new file mode 100644 > index 00000000..c0e2c07b > --- /dev/null > +++ b/test/tarantool-tests/fix-dangling-reference-to-ctype.test.lua > @@ -0,0 +1,59 @@ > +local tap = require('tap') > +local ffi = require('ffi') > +local test = tap.test('fix-dangling-reference-to-ctype'):skipcond({ > + -- luacheck: no global > + ['Impossible to predict the value of cts->top'] = _TARANTOOL, > +}) > + > +test:plan(1) > + > +-- This test demonstrates LuaJIT's incorrect behaviour when the > +-- reallocation of `cts->tab` strikes during the conversion of a > +-- TValue (cdata function pointer) to a C type. > +-- The test fails under ASAN. Let's change the last sentence to 'Before the patch the test fails only under ASAN' because now it is a bit misleading. > + > +-- XXX: Just some C functions to be casted. There is no need to > +-- declare their prototypes correctly. > +ffi.cdef[[ > + int malloc(void); > + int fprintf(void); > + int printf(void); > + int memset(void); > + int memcpy(void); > + int memmove(void); > + int getppid(void); > +]] > + > +-- XXX: structure to set `cts->top` to 110. > +local _ = ffi.new('struct {int a; long b; float c; double d;}', 0) > + > +-- Anchor table to prevent cdata objects from being collected. > +local anchor = {} > +-- Each call to this function grows `cts->top` by 3. Please drop a comment, referring to a point in sources, so the size of the growth becomes obvious. > +local function save_new_func(func) > + anchor[#anchor + 1] = ffi.cast('void (*)(void)', func) > +end > + > +save_new_func(ffi.C.malloc) -- `cts->top` = 110 > +save_new_func(ffi.C.fprintf) -- `cts->top` = 113 > +save_new_func(ffi.C.printf) -- `cts->top` = 116 > +save_new_func(ffi.C.memset) -- `cts->top` = 119 > +save_new_func(ffi.C.memcpy) -- `cts->top` = 122 Is it possible to bring us to this value of `cts->top` with a structure? > + > +-- Assertions to check the `cts->top` value and step between > +-- calls. > +assert(ffi.typeinfo(122), 'cts->top >= 122') > +assert(not ffi.typeinfo(123), 'cts->top < 123') > + > +save_new_func(ffi.C.memmove) -- `cts->top` = 125 > + > +assert(ffi.typeinfo(125), 'cts->top >= 125') > +assert(not ffi.typeinfo(126), 'cts->top < 126') > + > +-- Last call to grow `cts->top` up to 128, so this causes > +-- `cts->tab` reallocation. > +save_new_func(ffi.C.getppid) -- `cts->top` = 128 Should we add an extra assertion after reallocation? > + > +test:ok(true, 'no heap-use-after-free in lj_cconv_ct_tv') > + > +test:done(true) > -- > 2.42.0 >