From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755085AbbIIKXC (ORCPT ); Wed, 9 Sep 2015 06:23:02 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:56275 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753250AbbIIKWx (ORCPT ); Wed, 9 Sep 2015 06:22:53 -0400 Message-ID: <55F00861.7070306@huawei.com> Date: Wed, 9 Sep 2015 18:22:25 +0800 From: "long.wanglong" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Andrey Ryabinin CC: Andrey Konovalov , Andrew Morton , Rusty Russell , "linux-mm@kvack.org" , LKML , , , Subject: Re: [PATCH 2/2] kasan: Fix a type conversion error References: <1441771180-206648-1-git-send-email-long.wanglong@huawei.com> <1441771180-206648-3-git-send-email-long.wanglong@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.152.157] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015/9/9 17:40, Andrey Ryabinin wrote: > 2015-09-09 6:59 GMT+03:00 Wang Long : >> The current KASAN code can find the following out-of-bounds >> bugs: >> char *ptr; >> ptr = kmalloc(8, GFP_KERNEL); >> memset(ptr+7, 0, 2); >> >> the cause of the problem is the type conversion error in >> *memory_is_poisoned_n* function. So this patch fix that. >> >> Signed-off-by: Wang Long >> --- >> mm/kasan/kasan.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c >> index 7b28e9c..5d65d06 100644 >> --- a/mm/kasan/kasan.c >> +++ b/mm/kasan/kasan.c >> @@ -204,7 +204,7 @@ static __always_inline bool memory_is_poisoned_n(unsigned long addr, >> s8 *last_shadow = (s8 *)kasan_mem_to_shadow((void *)last_byte); >> >> if (unlikely(ret != (unsigned long)last_shadow || >> - ((last_byte & KASAN_SHADOW_MASK) >= *last_shadow))) >> + ((long)(last_byte & KASAN_SHADOW_MASK) >= *last_shadow))) > > Is there any problem if we just define last_byte as 'long' instead of > 'unsigned long' ? yes, I think it is not OK, because on my test, if we define last_byte as 'long' instead of 'unsigned long', the bug we talk about can not be found. > >> return true; >> } >> return false; >> -- >> 1.8.3.4 >> > > . >