From patchwork Fri Sep 10 20:31:52 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Collingbourne X-Patchwork-Id: 12486039 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=-26.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=ham 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 BB8E5C433EF for ; Fri, 10 Sep 2021 20:32:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5DF5E6109F for ; Fri, 10 Sep 2021 20:32:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5DF5E6109F Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id DC4DF6B0071; Fri, 10 Sep 2021 16:32:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D4ED86B0072; Fri, 10 Sep 2021 16:32:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA0AF900002; Fri, 10 Sep 2021 16:32:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0175.hostedemail.com [216.40.44.175]) by kanga.kvack.org (Postfix) with ESMTP id A76C66B0071 for ; Fri, 10 Sep 2021 16:32:02 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5C2DD8249980 for ; Fri, 10 Sep 2021 20:32:02 +0000 (UTC) X-FDA: 78572810484.13.9E99676 Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) by imf28.hostedemail.com (Postfix) with ESMTP id 10D9C90000B1 for ; Fri, 10 Sep 2021 20:32:01 +0000 (UTC) Received: by mail-yb1-f201.google.com with SMTP id f83-20020a25cf56000000b005a0445377e8so4014748ybg.20 for ; Fri, 10 Sep 2021 13:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=bpumMsZ/iH3OQI+CR6Z2vGKgSG1hOo6xv5zUNLG04h4=; b=lj7XkbVmNUB3dqEVKzQlirVNkYGsP2DW7hIh2ZMJPDFbjPP+iRh9bXgICPWbUCTOIF 6vqisBgdxNuq0wQX4ta50TM+bt1Td4I/M/g0Ojy2jURYP1MiXC7k1wJvQ69Rd4LWMaFT VdmunUHOnngDbZB0sz6vquTTenGmxMyvmJoptjrKw2gotvgMrlnnSBhZaG5tAYwP+gLG ggwXMXi9Ii6Ypw3/u25VolVquRt865SXFTDsw56GfHwYC6Egy7fpUlBtGtizanJwiiI2 JG7J5JIy82r+ypWz0SHbx30oNR1ZmAn4bhJ8+OH/xy3jfcJlljQh2YJPdyFGhdB1aGZZ y+Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=bpumMsZ/iH3OQI+CR6Z2vGKgSG1hOo6xv5zUNLG04h4=; b=3NEldlWECjklS5DxkvrI4CkhsZ0Lzfsm20eNpuhTzY44MXRq3bW+0F4fSK+ujwftkB /3IIIrbBwTrrTsq7IuXnqQWWwlNB0knftUjJSqDqZUl1npAjindyRkF8VYgE/TcsZKhd WNJRldlZ8LAkmQ4TJkPF1ajnmyyITN56wGIOLAVorv0EJPiKlvFxa2sg3BFZ0ySyKBGv +aoSxuLML86LcsYpQtTjx9huzqhtIKU57Nuwz7Ur6oEkvfJ+HXSPWbs2cs5viwmCLFBm cA4pqylD36hB/Jc3B3e+DiynnbUfZ8ZotuenA0Vx1F6DdZvfi4WLgXvTJKOX1vauTe2E gzsg== X-Gm-Message-State: AOAM5316tvbaOho6bNHWz7cpiCebP0F2pSqqpObc4RsmtohBCBmfzEWa xsvSHWjM5qPv8TvxhJjX9cYctrY= X-Google-Smtp-Source: ABdhPJwsyZwIJKziWvVICpTqJDjA68fre7Lsq1Q0JURHbn7vTd+SH7vqUt/NZs2RlzlGnCUIYOyzfWQ= X-Received: from pcc-desktop.svl.corp.google.com ([2620:15c:2ce:200:90e5:d30e:ae0f:6c1]) (user=pcc job=sendgmr) by 2002:a25:bb08:: with SMTP id z8mr13711680ybg.306.1631305921292; Fri, 10 Sep 2021 13:32:01 -0700 (PDT) Date: Fri, 10 Sep 2021 13:31:52 -0700 Message-Id: <20210910203152.3549236-1-pcc@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.33.0.309.g3052b89438-goog Subject: [PATCH] kasan: test: don't copy more than size bytes in memcpy test From: Peter Collingbourne To: Robin Murphy , Will Deacon , Catalin Marinas , Andrey Konovalov , Marco Elver Cc: Peter Collingbourne , Mark Rutland , Evgenii Stepanov , Alexander Potapenko , Linux ARM , linux-mm@kvack.org Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=lj7XkbVm; spf=pass (imf28.hostedemail.com: domain of 3wcA7YQMKCEItggksskpi.gsqpmry1-qqozego.svk@flex--pcc.bounces.google.com designates 209.85.219.201 as permitted sender) smtp.mailfrom=3wcA7YQMKCEItggksskpi.gsqpmry1-qqozego.svk@flex--pcc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: fw1djr5s15jhwahkzoscgxew33dxywcj X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 10D9C90000B1 X-HE-Tag: 1631305921-767592 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: With HW tag-based KASAN, error checks are performed implicitly by the load and store instructions in the memcpy implementation. A failed check results in tag checks being disabled and execution will keep going. As a result, under HW tag-based KASAN, this memcpy would end up corrupting memory until it hits an inaccessible page and causes a kernel panic. This is a pre-existing issue that was revealed by commit 285133040e6c ("arm64: Import latest memcpy()/memmove() implementation") which changed the memcpy implementation from using signed comparisons (incorrectly, resulting in the memcpy being terminated early for negative sizes) to using unsigned comparisons. It is unclear how this could be handled by memcpy itself in a reasonable way. One possibility would be to add an exception handler that would force memcpy to return if a tag check fault is detected -- this would make the behavior roughly similar to generic and SW tag-based KASAN. However, this wouldn't solve the problem for asynchronous mode and also makes memcpy behavior inconsistent with manually copying data. It may be more accurate to consider this a bug in the test: what we really want to test here is that a memcpy overflow, however small, is caught, and any further copying after the initial overflow is unnecessary and may affect system stability. Therefore, adjust the test to pass the allocation size as the memcpy size, ensuring that the memcpy will not result in an out-of-bounds write. Commit 1b0668be62cf ("kasan: test: disable kmalloc_memmove_invalid_size for HW_TAGS") disabled this test in HW tags mode, but there is some value in testing small memcpy overflows, so let's re-enable it with this fix. Link: https://linux-review.googlesource.com/id/I048d1e6a9aff766c4a53f989fb0c83de68923882 Signed-off-by: Peter Collingbourne --- lib/test_kasan.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/lib/test_kasan.c b/lib/test_kasan.c index 8835e0784578..9af51e1f692d 100644 --- a/lib/test_kasan.c +++ b/lib/test_kasan.c @@ -497,14 +497,7 @@ static void kmalloc_memmove_invalid_size(struct kunit *test) { char *ptr; size_t size = 64; - volatile size_t invalid_size = -2; - - /* - * Hardware tag-based mode doesn't check memmove for negative size. - * As a result, this test introduces a side-effect memory corruption, - * which can result in a crash. - */ - KASAN_TEST_NEEDS_CONFIG_OFF(test, CONFIG_KASAN_HW_TAGS); + volatile size_t invalid_size = size; ptr = kmalloc(size, GFP_KERNEL); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ptr);