Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp5572049ybp; Tue, 8 Oct 2019 05:10:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxt2kluAI7gG5IBH/tRn6K5w4XuasgouAV3IGlPJBEqy7X8T1ewETJWIGDOWwbZ57WB6aqY X-Received: by 2002:a05:6402:1f4:: with SMTP id i20mr33662400edy.137.1570536651676; Tue, 08 Oct 2019 05:10:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570536651; cv=none; d=google.com; s=arc-20160816; b=Cn+QcKXz/GFSFD7k9XvZqjCkDv55yAAxvhO+0xJFKZ6li6SDKwF2L4su5rvNSeO87C jmiNO7WP9oIu/Ib8p2HvKDEDRkrTgaP4buucMa1qVWobeRt9WTLAv4lSGM6DkjYMvriA WiYuLK1NbITbPtOGMeDbPTia1tlYQJEwa99KYF4sy987vXD7I8eQCWBdZNjji3OqIcmF oD13cQ4oSzPN2Ag3x4gwt2rVQS977zSlHeIwIp55rvz7IhQklQ373TX5glqIwhfn0x3/ b8ayCu0bbbOkPowWRry7QvLLflNCdAU3Es3ZLULdpIxlkk9lgMVB6AeEoO+8ltaQf4+h OjxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :references:in-reply-to:date:cc:to:from:subject:message-id; bh=dMleiwFnuHxNmBt/IgHWd5QJozfjf807QRhDOO4Xka8=; b=RJA+6syvLUXQHzQSmovkbuKQiwDoXXAtlvCtilp/i1n5rDCMVaNpjAEFE8pOzyI82a Eli9GUvxgDyQyHH3q6iBPChfoB2vc6AlJZ8uk0J1hsb+kAPUFqN5oloag17+q7hV6Nxt 8KXnYI7WMUVhIKB5yNSbzumqpOYGnGw/A9JXFgN0kE5D9ANB4QlRsvRe3CRDZ8iOZ0Ye SmdHIUtoiQek51nSmO73xkXgekcNtzKLoXpZjF9twVNpyrf7l5BtRacGi/13EvjwUu1x yhqutQ5Tv1hW5Kicss4xOTlOEVrpN83CLj+j8SPOmGpOeCbHFzwi90iHe0BN5zwBVmdT bg5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v8si10797255edi.22.2019.10.08.05.10.27; Tue, 08 Oct 2019 05:10:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730840AbfJHMHr (ORCPT + 99 others); Tue, 8 Oct 2019 08:07:47 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:10674 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1730727AbfJHMHr (ORCPT ); Tue, 8 Oct 2019 08:07:47 -0400 X-UUID: 134220af59d1465ebc8848ae4483be8b-20191008 X-UUID: 134220af59d1465ebc8848ae4483be8b-20191008 Received: from mtkcas08.mediatek.inc [(172.21.101.126)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 815412962; Tue, 08 Oct 2019 20:07:41 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs07n1.mediatek.inc (172.21.101.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 8 Oct 2019 20:07:38 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 8 Oct 2019 20:07:38 +0800 Message-ID: <1570536459.4686.109.camel@mtksdccf07> Subject: Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y From: Walter Wu To: Qian Cai CC: Dmitry Vyukov , Andrey Ryabinin , Alexander Potapenko , Matthias Brugger , LKML , kasan-dev , Linux-MM , Linux ARM , , wsd_upstream Date: Tue, 8 Oct 2019 20:07:39 +0800 In-Reply-To: References: <1570532528.4686.102.camel@mtksdccf07> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2019-10-08 at 07:42 -0400, Qian Cai wrote: > > > On Oct 8, 2019, at 7:02 AM, Walter Wu wrote: > > > > I don't know very well in UBSAN, but I try to build ubsan kernel and > > test a negative number in memset and kmalloc_memmove_invalid_size(), it > > look like no check. > > It sounds like more important to figure out why the UBSAN is not working in this case rather than duplicating functionality elsewhere. Maybe we can let the maintainer and reviewer decide it :) And We want to say if size is negative numbers, it look like an out-of-bounds, too. so KASAN make sense to detect it.