From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: [patch 007/128] usercopy: mark dma-kmalloc caches as usercopy caches Date: Mon, 01 Jun 2020 21:45:43 -0700 Message-ID: <20200602044543.U9huDju4a%akpm@linux-foundation.org> References: <20200601214457.919c35648e96a2b46b573fe1@linux-foundation.org> Reply-To: linux-kernel@vger.kernel.org Return-path: Received: from mail.kernel.org ([198.145.29.99]:36300 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725793AbgFBEpp (ORCPT ); Tue, 2 Jun 2020 00:45:45 -0400 In-Reply-To: <20200601214457.919c35648e96a2b46b573fe1@linux-foundation.org> Sender: mm-commits-owner@vger.kernel.org List-Id: mm-commits@vger.kernel.org To: akpm@linux-foundation.org, borntraeger@de.ibm.com, christoffer.dall@linaro.org, cl@linux.com, dave.kleikamp@oracle.com, dave@nullcore.net, davem@davemloft.net, hch@infradead.org, iamjoonsoo.kim@lge.com, jack@suse.cz, jannh@google.com, jslaby@suse.cz, jwi@linux.ibm.com, labbott@redhat.com, linux-mm@kvack.org, luisbg@kernel.org, luto@kernel.org, marc.zyngier@arm.com, mark.rutland@arm.com, martin.petersen@oracle.com, mjg59@google.com, mkubecek@suse.cz, mm-commits@vger.kernel.org, pbonzini@redhat.com, penberg@kernel.org, riel@surriel.com, rientjes@google.com, torvalds@linux-foundation.org, ubraun@linux.ibm.com, vbabka@suse.cz, viro@zeniv.linux.org.uk From: Vlastimil Babka Subject: usercopy: mark dma-kmalloc caches as usercopy caches 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/ Link: http://lkml.kernel.org/r/7d810f6d-8085-ea2f-7805-47ba3842dc50@suse.cz Signed-off-by: Vlastimil Babka 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: Linus Torvalds 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 Signed-off-by: Andrew Morton --- mm/slab_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/slab_common.c~usercopy-mark-dma-kmalloc-caches-as-usercopy-caches +++ a/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 _