]> 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)
commit91d4aabd641804ff91e9fea3517b13fbc60a3f78
tree21155537ed0c47f2ae62ac49e4e9a93a2bba2eb3
parent0fa111e2e874286f4273e6fa28c4bb3ae515be86
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 ebff6b8f816c ("[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