ACK: [SRU][F][PATCH 0/1] Problem leading IUCV service down (on s390x) (LP: 1913442)

[Tim Gardner]

Acked-by: Tim Gardner <tim.gardner at canonical.com>

On 10/5/21 12:32 AM, frank.heimes at canonical.com wrote:
> BugLink: https://bugs.launchpad.net/bugs/1913442
> 
> SRU Justification:
> 
> [Impact]
> 
> * Problems occur in IBM z/VM's IUCV (Inter User Communication Vehicle) environments and its communication.
> 
> * Errors like "usercopy: Kernel memory overwrite attempt detected to SLUB object 'dma-kmalloc-1 k' (offset 0, size 11)!" pop up and cause failures.
> 
> * This is because IUCV uses kmalloc() with __GFP_DMA because of memory address restrictions.
> 
> * The solution is to mark dma-kmalloc caches as usercopy caches.
> 
> [Fix]
> 
> * 49f2d2419d60a103752e5fbaf158cf8d07c0d884 49f2d2419d60 "usercopy: mark dma-kmalloc caches as usercopy caches"
> 
> * Due to changes in the context of the upstream patch,
>    a cherry-pick was not possible and the following backport was created:
>    https://bugs.launchpad.net/bugs/1913442/+attachment/5457885/+files/commit_49f2d2419d60_backport.patch
> 
> [Test Case]
> 
> * Setup Ubuntu Server 20.04 on s390x system as IBM z/VM guest aka virtual machine.
> 
> * Setup IUCV on z/VM: Setting up the (IUCV TCPIP) service machine:
> https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_t_iucv_tcpservice.html
> 
> * Set up a Linux IUCV instance: https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_t_iucv_scen1_guest.html
> 
> * Set up an IUCV direct: https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.ljdd/ljdd_c_iucv_connect.html
> 
> * Make use of IUCV, for example using ssh on a direct connection.
> 
> * Verify if the connections is stable and watch out for messages starting with "usercopy".
> 
> [Regression Potential]
> 
> * Problems could occure in case the create_kmalloc_cache call is done wrong,
>    for example with wrong index, wrong size or just wrong comma separations.
> 
> * Wrong size or index will probably lead to similar instability problems that exist today.
> 
> * Problems in the syntax (commas etc.) will be detected at compile time.
> 
> * But it's just a single line modification in function create_kmalloc_caches of /mm/slab_common.c,
> 
> * so the change is very limited and quite traceable.
> 
> * And it was in depth discussed here:
>    https://lore.kernel.org/kernel-hardening/1515636190-24061-2-git-send-email-keescook@chromium.org/
> 
> * a reviewed by a lot of kernel engineers (see provenance)
> 
> * and it was already upstream accepted with kernel 5.8.
> 
> [Other]
> 
> * Since the commit is upstream accepted with 5.8, it's already in groovy and hirsute.
> 
> * Hence this kernel SRU submission is for Focal only and covers only the above single but common code commit/patch.
> 
> Frank Heimes (1):
>    usercopy: mark dma-kmalloc caches as usercopy caches
> 
>   mm/slab_common.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

-- 
-----------
Tim Gardner
Canonical, Inc