From patchwork Tue Oct 5 06:32:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Frank Heimes X-Patchwork-Id: 1536506 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.a=rsa-sha256 header.s=20210705 header.b=cMPLlhg2; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4HNnpD166Tz9sPf for ; Tue, 5 Oct 2021 17:33:08 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1mXe0a-0003XT-6Z; Tue, 05 Oct 2021 06:33:00 +0000 Received: from smtp-relay-canonical-1.internal ([10.131.114.174] helo=smtp-relay-canonical-1.canonical.com) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1mXe0X-0003XA-Ca for kernel-team@lists.ubuntu.com; Tue, 05 Oct 2021 06:32:57 +0000 Received: from T570.fritz.box (p54abb16c.dip0.t-ipconnect.de [84.171.177.108]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-canonical-1.canonical.com (Postfix) with ESMTPSA id 170C93F328 for ; Tue, 5 Oct 2021 06:32:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1633415577; bh=CWWfMC35QACpvgXpGGRG06i2TzH5djCydWy9HMFKpnE=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=cMPLlhg2OXgpI0kYUGywpetT+GXRRjPxTlkSHJa+H/i2qn5p98nEN8TlJU+xSNjdx ZoPG6cbytFWhtxxOwp9v26Hj7C4SzlXOXfvdOc7i0MDHp9s2kIwtOL6o6SpuorWgr+ Di6dDM0SgmSQwmX4D5RSnDLiTGilFS3whHnoutbz0U+KByRpHVoe8EjrPrShUwmGT3 G+AgJ4W4S1G+LjcDHkXP0qVzKua6DavO4ZkO+F0q/+pKB44AHtrKwpBsnFdUpXNARo wv7bOmHzOYsZlL3mP7BPcAjPhfzlUihFxcrdSl6an+JolQwN9mPoizz+DYZBly2y+0 RYbE/2d+gmyzQ== From: frank.heimes@canonical.com To: kernel-team@lists.ubuntu.com Subject: [SRU][F][PATCH 1/1] usercopy: mark dma-kmalloc caches as usercopy caches Date: Tue, 5 Oct 2021 08:32:20 +0200 Message-Id: <20211005063220.1513915-2-frank.heimes@canonical.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211005063220.1513915-1-frank.heimes@canonical.com> References: <20211005063220.1513915-1-frank.heimes@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Vlastimil Babka BugLink: https://bugs.launchpad.net/bugs/1913442 Upstream commit : 49f2d2419d60a103752e5fbaf158cf8d07c0d884 We have seen a "usercopy: Kernel memory overwrite attempt detected to SLUB object 'dma-kmalloc-1 k' (offset 0, size 11)!" error on s390x, as IUCV uses kmalloc() with __GFP_DMA because of memory address restrictions. The issue has been discussed [2] and it has been noted that if all the kmalloc caches are marked as usercopy, there's little reason not to mark dma-kmalloc caches too. The 'dma' part merely means that __GFP_DMA is used to restrict memory address range. As Jann Horn put it [3]: "I think dma-kmalloc slabs should be handled the same way as normal kmalloc slabs. When a dma-kmalloc allocation is freshly created, it is just normal kernel memory - even if it might later be used for DMA -, and it should be perfectly fine to copy_from_user() into such allocations at that point, and to copy_to_user() out of them at the end. If you look at the places where such allocations are created, you can see things like kmemdup(), memcpy() and so on - all normal operations that shouldn't conceptually be different from usercopy in any relevant way." Thus this patch marks the dma-kmalloc-* caches as usercopy. [1] https://bugzilla.suse.com/show_bug.cgi?id=1156053 [2] https://lore.kernel.org/kernel-hardening/bfca96db-bbd0-d958-7732-76e36c667c68@suse.cz/ [3] https://lore.kernel.org/kernel-hardening/CAG48ez1a4waGk9kB0WLaSbs4muSoK0AYAVk8=XYaKj4_+6e6Hg@mail.gmail.com/ Signed-off-by: Vlastimil Babka Signed-off-by: Andrew Morton Acked-by: Christian Borntraeger Acked-by: Jiri Slaby Cc: Jann Horn Cc: Christoph Hellwig Cc: Christopher Lameter Cc: Julian Wiedmann Cc: Ursula Braun Cc: Alexander Viro Cc: David Windsor Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Andy Lutomirski Cc: "David S. Miller" Cc: Laura Abbott Cc: Mark Rutland Cc: "Martin K. Petersen" Cc: Paolo Bonzini Cc: Christoffer Dall Cc: Dave Kleikamp Cc: Jan Kara Cc: Luis de Bethencourt Cc: Marc Zyngier Cc: Rik van Riel Cc: Matthew Garrett Cc: Michal Kubecek Link: http://lkml.kernel.org/r/7d810f6d-8085-ea2f-7805-47ba3842dc50@suse.cz Signed-off-by: Linus Torvalds (backported from commit 49f2d2419d60a103752e5fbaf158cf8d07c0d884) Signed-off-by: Frank Heimes Acked-by: Krzysztof Kozlowski --- mm/slab_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/slab_common.c b/mm/slab_common.c index 8c1ffbf7de45..76433e2187d0 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1296,7 +1296,7 @@ void __init create_kmalloc_caches(slab_flags_t flags) BUG_ON(!n); kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache( - n, size, SLAB_CACHE_DMA | flags, 0, 0); + n, size, SLAB_CACHE_DMA | flags, 0, kmalloc_info[i].size); } } #endif