From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id B3998469710 for ; Tue, 19 May 2020 19:21:30 +0300 (MSK) References: From: Aleksandr Lyapunov Message-ID: <08e98cac-49e7-c3c0-616f-13818f6ccd2b@tarantool.org> Date: Tue, 19 May 2020 19:21:29 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: [Tarantool-patches] [PATCH small 1/1] lsregion: fix slab_unmap() called on malloced slab List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org, korablev@tarantool.org Thank for the patch! nice catch, lgtm! On 5/15/20 1:31 AM, Vladislav Shpilevoy wrote: > Lsregion allocates slabs using either > - Slab_map() from slab arena, when allocation size is smaller, > than slab size; > - Using cached slab, stored in the lsregion as a protection from > oscillation; > - Using malloc(), when requested size is too big. > > Malloc() was used when allocation size was >= fixed slab size - > meta size. However free() was used, when real slab size was > > fixed slab size - meta size. So if an allocation was exactly of > size 'fixed slab size - meta size', it was allocated using > malloc(), but freed using slab_unmap(). That lead to a crash, if > 'lucky'. But as it is a memory corruption, could lead to anything. > --- > Branch: http://github.com/tarantool/small/tree/gerold103/fix-lsregion-crash-or-leak > > This led to at least leaks in vinyl. Since it used lsregion very > extensively for 0 level of LSM trees.