]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commitd0b0ac75b071dbbee525b7c737876ad1c9b0c012
tree21155537ed0c47f2ae62ac49e4e9a93a2bba2eb3
parent5532ff9d694117ab6791f462ffde99a5011aed82
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 84aeb83db417 ("[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 25fbd3baf2b6 ("[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: 84aeb83db417 ("[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