From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A05FC4CECE for ; Mon, 14 Oct 2019 02:19:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3D6F7207FF for ; Mon, 14 Oct 2019 02:19:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3D6F7207FF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8805B8E0005; Sun, 13 Oct 2019 22:19:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 830068E0001; Sun, 13 Oct 2019 22:19:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 746D08E0005; Sun, 13 Oct 2019 22:19:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 525748E0001 for ; Sun, 13 Oct 2019 22:19:56 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id E9593180ACF7F for ; Mon, 14 Oct 2019 02:19:55 +0000 (UTC) X-FDA: 76040784750.29.news99_5688ccc31eb37 X-HE-Tag: news99_5688ccc31eb37 X-Filterd-Recvd-Size: 3133 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Mon, 14 Oct 2019 02:19:54 +0000 (UTC) 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 X-Bogosity: Ham, tests=bogofilter, spamicity=0.027086, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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.