From 8c6492027d31fc88ff2e83eb0c4adf0d15cd240d Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 15 Jun 2020 15:28:11 +0200 Subject: [PATCH] 5.7-stable patches added patches: usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch --- queue-5.7/series | 1 + ...ma-kmalloc-caches-as-usercopy-caches.patch | 82 +++++++++++++++++++ 2 files changed, 83 insertions(+) create mode 100644 queue-5.7/usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch diff --git a/queue-5.7/series b/queue-5.7/series index a4c46198477..e94f9d1dbd6 100644 --- a/queue-5.7/series +++ b/queue-5.7/series @@ -31,3 +31,4 @@ padata-add-separate-cpuhp-node-for-cpuhp_padata_dead.patch kvm-x86-only-do-l1tf-workaround-on-affected-processors.patch pci-pm-adjust-pcie_wait_for_link_delay-for-caller-de.patch aio-fix-async-fsync-creds.patch +usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch diff --git a/queue-5.7/usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch b/queue-5.7/usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch new file mode 100644 index 00000000000..4d27dbcc655 --- /dev/null +++ b/queue-5.7/usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch @@ -0,0 +1,82 @@ +From 49f2d2419d60a103752e5fbaf158cf8d07c0d884 Mon Sep 17 00:00:00 2001 +From: Vlastimil Babka +Date: Mon, 1 Jun 2020 21:45:43 -0700 +Subject: usercopy: mark dma-kmalloc caches as usercopy caches + +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 -- 2.47.3