From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by sourceware.org (Postfix) with ESMTPS id 1737C385782F for ; Fri, 23 Apr 2021 02:23:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1737C385782F Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FRJ0h0dVjzpb9q; Fri, 23 Apr 2021 10:20:20 +0800 (CST) Received: from [10.174.177.224] (10.174.177.224) by DGGEMS404-HUB.china.huawei.com (10.3.19.204) with Microsoft SMTP Server id 14.3.498.0; Fri, 23 Apr 2021 10:23:13 +0800 Subject: Re: [PATCH] malloc: Print error when oldsize is not equal to the current size. To: DJ Delorie CC: , , Liusirui References: From: liqingqing Message-ID: <1128ec85-bd4f-a6e8-cc3b-ae17aa94d96b@huawei.com> Date: Fri, 23 Apr 2021 10:23:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.174.177.224] X-CFilter-Loop: Reflected X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2021 02:23:27 -0000 On 2021/4/14 6:14, DJ Delorie wrote: > liqingqing writes: >> the read of the oldsize is not protected by any lock, so check this value to avoid causing bigger mistakes.  > Normally nothing can change oldsize until the oldp chunk is returned to > the arena, and at the point where you added the check that hasn't > happened. Could you be more specific about how this value might change > out from under us? > > Is this a case of "some other thread might corrupt this"? But that can > happen regardless of lock. > > Are you assuming some other malloc/free call could corrupt oldsize while > they hold the lock? If so, is there a published exploit description for > this? > > . >> hello DJ, thanks for your reply. there have two scenarios, 1, if two threads  call  realloc at the same time, and for the same  ptr.    cause the oldsize is not protected by any lock, so if one thread has already finish resize the ptr and update the size,   but the other thread still use the oldsize. so  after this thread got the mutex lock “__libc_lock_lock (ar_ptr->mutex)” in the _int_realloc,   we should verify the  oldsize again. 2, two threads, one call free and the other call realloc,  with the same ptr.     if the first " free" thread trigger memory consolidate and modify the ptr's size,     and then the other "realloc"  thread get the lock , but still use the oldsize, this'will cause corrupt. although the man page has said this  will course unknow behavior, but i think this patch can reduce the impact.