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: 12486053 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=-17.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=unavailable 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 8E5BCC433F5 for ; Fri, 10 Sep 2021 20:37:09 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4F1C3611C3 for ; Fri, 10 Sep 2021 20:37:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4F1C3611C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Mime-Version: Message-Id:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=Y8BTnBxDznhItwGyUvJXQMSIFBRaxsfP2dnfUl5cvaE=; b=q7V sjPfVc7bACh7+kr3zE0Df4l54AFnTUGdU2I3w03YIYIasXMF0c79henJTg4HHDkYyPg7i/3xJH3eu YaWAu820XUuiif6QaSM14Olg0AfUGId8LS2UnpFgbGlEAsMqO20pQLG8zWtq2OUsFzH3InfhzY0kN qrfjmtieRr1eMMYYv7E/eiBdT4CXhdiB0N7+unymSwMAxgXwuZJWsNi23hKVFllhjpqsPU8OoC7Kj bR1R1ppt0X3cAT/ve4pOQfowJL17Kx0TCOxZTTuYh7OQjQ0E2vfjWr7OM3ghsgWtNga/O3BKUQ9Im x5SCg6uzkHLv418hCb7JQ5h4m+SIGkw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mOnEI-00DjJ5-FE; Fri, 10 Sep 2021 20:34:35 +0000 Received: from mail-yb1-xb4a.google.com ([2607:f8b0:4864:20::b4a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mOnBr-00Di4p-Io for linux-arm-kernel@lists.infradead.org; Fri, 10 Sep 2021 20:32:05 +0000 Received: by mail-yb1-xb4a.google.com with SMTP id z6-20020a257e06000000b0059bad6decfbso3986612ybc.16 for ; Fri, 10 Sep 2021 13:32:02 -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=GhbibYuVZRm3Bq+JS8Y8mYn9X2+G1jFINgd4UodFAkw++jaR2M37ysDH6uW+xHdAbl +wRpo/U6cObDAS+mGlFGuVjndxq7IOkvd17CmXQLCIf5I2ISricT2gJ6rowslGu74USy DVRLcZMnFhU8gZeyqxUsn0/Qgwm4/F3kdqbIa5RMpKgkAYYtI1ei8b9FAF0wUnjZV2T1 /CiA6otYBqIvVbeNu+V3ByIzZPsoLcxjc+rFH94vZ9wV+gTTHXuBhTau7r532jwP9gbd SCCkLfu3fj2KxuzX+BDFD4/glqfCeKYWoTCplcql5LR5qy0u7pmu+5o2pBcQsY1cJMKL Uphw== X-Gm-Message-State: AOAM5335WEBar8UzsmqF3gardhssqqzaHHdkACJulW/rfljFMjm6NWcz dQisr7zrL9oNd/51hwO0yflCfSM= 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210910_133203_704077_954E5A44 X-CRM114-Status: GOOD ( 18.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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);