OSDN Git Service

s390: fix stfle zero padding
authorHeiko Carstens <heiko.carstens@de.ibm.com>
Mon, 17 Jun 2019 12:02:41 +0000 (14:02 +0200)
committerVasily Gorbik <gor@linux.ibm.com>
Wed, 19 Jun 2019 15:54:27 +0000 (17:54 +0200)
commit4f18d869ffd056c7858f3d617c71345cf19be008
tree21155537ed0c47f2ae62ac49e4e9a93a2bba2eb3
parent191fa92b344831e3d1b15e0bf698dfe9755a81d2
s390: fix stfle zero padding

The stfle inline assembly returns the number of double words written
(condition code 0) or the double words it would have written
(condition code 3), if the memory array it got as parameter would have
been large enough.

The current stfle implementation assumes that the array is always
large enough and clears those parts of the array that have not been
written to with a subsequent memset call.

If however the array is not large enough memset will get a negative
length parameter, which means that memset clears memory until it gets
an exception and the kernel crashes.

To fix this simply limit the maximum length. Move also the inline
assembly to an extra function to avoid clobbering of register 0, which
might happen because of the added min_t invocation together with code
instrumentation.

The bug was introduced with commit 14375bc4eb8d ("[S390] cleanup
facility list handling") but was rather harmless, since it would only
write to a rather large array. It became a potential problem with
commit 3ab121ab1866 ("[S390] kernel: Add z/VM LGR detection"). Since
then it writes to an array with only four double words, while some
machines already deliver three double words. As soon as machines have
a facility bit within the fifth double a crash on IPL would happen.

Fixes: 14375bc4eb8d ("[S390] cleanup facility list handling")
Cc: <stable@vger.kernel.org> # v2.6.37+
Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
arch/s390/include/asm/facility.h