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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 1F9D1C433E0 for ; Tue, 16 Jun 2020 15:50:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03E1B21508 for ; Tue, 16 Jun 2020 15:50:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592322644; bh=cfc5FjrY9vBGbt70tlqFyKkXVCs/JWORPS2LyxaMb0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Vvh0vWnzinhlu7CnVtbtXA7ybClJg6RTia+fQ4IwNYiU27H4iNunfdO9jlGnEZ1c0 7NE7En//8Qk+EvmmILo2qWFZ+ZxM7v09nEjJv9h97imUKkUXzqlSo+6CtKUW/RdC8U 0SybQOhwJ6JbJaHHsICE1lQ8X7Wk/dlY2Rwdhm/Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732158AbgFPPun (ORCPT ); Tue, 16 Jun 2020 11:50:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:46662 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732612AbgFPPul (ORCPT ); Tue, 16 Jun 2020 11:50:41 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 85F4021473; Tue, 16 Jun 2020 15:50:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592322640; bh=cfc5FjrY9vBGbt70tlqFyKkXVCs/JWORPS2LyxaMb0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kko9/Ow/eR2P1/LvbMYef1DtH+6OlUyR2SzfcYZeyN2kP5DkazNQV12zTxByZoZp7 /Hch2jsHTN86ER7vscNmJh+tqWWKGGwExCzisxkM8SA1SCumSUzXe8bQYncEYMJlCH 8zHhssH/F5pDtu3brPPaErXgHmTj2B35t9fVG1Y4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vlastimil Babka , Andrew Morton , Christian Borntraeger , Jiri Slaby , Jann Horn , Christoph Hellwig , Christopher Lameter , Julian Wiedmann , Ursula Braun , Alexander Viro , David Windsor , Pekka Enberg , David Rientjes , Joonsoo Kim , Andy Lutomirski , "David S. Miller" , Laura Abbott , Mark Rutland , "Martin K. Petersen" , Paolo Bonzini , Christoffer Dall , Dave Kleikamp , Jan Kara , Luis de Bethencourt , Marc Zyngier , Rik van Riel , Matthew Garrett , Michal Kubecek , Linus Torvalds Subject: [PATCH 5.6 047/161] usercopy: mark dma-kmalloc caches as usercopy caches Date: Tue, 16 Jun 2020 17:33:57 +0200 Message-Id: <20200616153108.615520697@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200616153106.402291280@linuxfoundation.org> References: <20200616153106.402291280@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Vlastimil Babka commit 49f2d2419d60a103752e5fbaf158cf8d07c0d884 upstream. 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 Signed-off-by: Greg Kroah-Hartman --- mm/slab_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -1303,7 +1303,8 @@ void __init create_kmalloc_caches(slab_f kmalloc_caches[KMALLOC_DMA][i] = create_kmalloc_cache( kmalloc_info[i].name[KMALLOC_DMA], kmalloc_info[i].size, - SLAB_CACHE_DMA | flags, 0, 0); + SLAB_CACHE_DMA | flags, 0, + kmalloc_info[i].size); } } #endif