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

[frank.heimes at canonical.com]

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(-)

-- 
2.25.1