On 6/15/20 1:04 PM, Christian Borntraeger wrote: > > > On 02.06.20 22:10, Andrew Morton wrote: >> From: Vlastimil Babka <vbabka@xxxxxxx> >> 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@xxxxxxx/ >> [3] https://lore.kernel.org/kernel-hardening/CAG48ez1a4waGk9kB0WLaSbs4muSoK0AYAVk8=XYaKj4_+6e6Hg@xxxxxxxxxxxxxx/ >> >> Link: http://lkml.kernel.org/r/7d810f6d-8085-ea2f-7805-47ba3842dc50@xxxxxxx >> Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx> >> Acked-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >> Acked-by: Jiri Slaby <jslaby@xxxxxxx> > > We have also seen this with other drivers (vmur). Shouldnt this also go via stable? Why not, will you send it there? Thanks, Vlastimil
