Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp3993184ybp; Sun, 13 Oct 2019 19:26:27 -0700 (PDT) X-Google-Smtp-Source: APXvYqwrqPu5ApvmpaTRFuUnEu8MLVXE+2dXwPOyd7FtfR0A3Jm5hYOtWXZvpIpmmFZp8pByjsX6 X-Received: by 2002:a17:906:80cd:: with SMTP id a13mr26755257ejx.12.1571019987122; Sun, 13 Oct 2019 19:26:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571019987; cv=none; d=google.com; s=arc-20160816; b=BBH/+fDnhZgeiYQAqERRoOUx/eyMMlaYYV21RqCVN2Llpq/MwiS1+SEqoqRrTHtIy6 Z+MClunmSvHyZQkw0h9ASY3ttnKF7WgJnk7aIk8ua9BaouzvWhO8rsy9GwgHfLJ+bq4c ZUf5EPI7gA5gSUd2IZoPP1Hr6TZmbmFgcMlwWe5SfOew7pm9H2TKKH6tBYLQIS0yIHi3 og82XGTIIvd/C+Ne0r6uJ4l0k+Ka4v0slVmOQEEq7qCpqSTRo97+VDvG9GRP1j8NuPre JYl2BFSYDIGp8HAe91UmK0p3Gip5iacbDtsMcncXy01odnJCTFr1VfSuB7fTy1T8SNY8 vjUw== 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=5kmVFN1f9lFrdbPJWhmDkpTllSTKgW4kOPHCZocwYdA=; b=jKMQP5SFHruo8SAOOOTEfFmobawiBEjWqdIiGcAtNKl7CQPEOIZOvAAvSvBsw25zg3 vdDS2T9+jEmxq5ZF3lvIWXwvlEOOycCA8HUdOp6XePV3qDbBgWy5dkNw9IN1RtPpBkUE 4Yv+qQBYKUYEC8rljpElHBc2UMzsifYAKEZ95WMPs8Vxccmv2Xr4zFYGN+dPZlfOJbK4 BEr7s+d0ZgkTUkdSO57d7Pvvceir05SNhTnDwu+wrK6QonJtRG3v6BZPm0bfsu3hocnr /pepYLgrf4K1t29NRWiwZpHBgBByuDaAEb4jz9qu0+CZQr5tkCSlJzRKkfoQSUcd5hYI Nnxg== 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 d15si10596397edq.430.2019.10.13.19.25.51; Sun, 13 Oct 2019 19:26:27 -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 S1729769AbfJNCT5 (ORCPT + 99 others); Sun, 13 Oct 2019 22:19:57 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:22609 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1729474AbfJNCT4 (ORCPT ); Sun, 13 Oct 2019 22:19:56 -0400 X-UUID: fcb45f13d48f4e009d0c4926b41054a7-20191014 X-UUID: fcb45f13d48f4e009d0c4926b41054a7-20191014 Received: from mtkmrs01.mediatek.inc [(172.21.131.159)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 800004060; Mon, 14 Oct 2019 10:19:43 +0800 Received: from MTKCAS06.mediatek.inc (172.21.101.30) by mtkmbs07n2.mediatek.inc (172.21.101.141) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 14 Oct 2019 10:19:40 +0800 Received: from [172.21.84.99] (172.21.84.99) by MTKCAS06.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Mon, 14 Oct 2019 10:19:41 +0800 Message-ID: <1571019582.26230.8.camel@mtksdccf07> Subject: Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y From: Walter Wu To: Dmitry Vyukov CC: Qian Cai , Andrey Ryabinin , Alexander Potapenko , Matthias Brugger , LKML , kasan-dev , Linux-MM , Linux ARM , , wsd_upstream Date: Mon, 14 Oct 2019 10:19:42 +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 14:11 +0200, Dmitry Vyukov wrote: > On Tue, Oct 8, 2019 at 1:42 PM 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. > > Detecting out-of-bounds accesses is the direct KASAN responsibility. > Even more direct than for KUBSAN. We are not even adding > functionality, it's just a plain bug in KASAN code, it tricks itself > into thinking that access size is 0. > Maybe it's already detected by KUBSAN too? Thanks for your response. I survey the KUBSAN, it don't check size is negative in memset/memcpy/memmove, we try to verify our uni testing too, it don't report the bug in KUBSAN, so it needs to report this bug by KASAN. The reason is like what you said. so we still send the patch.