summaryrefslogtreecommitdiff
path: root/crypto/dh_helper.c
diff options
context:
space:
mode:
authorCyril Bur <cyrilbur@gmail.com>2017-08-17 20:42:26 +1000
committerMichael Ellerman <mpe@ellerman.id.au>2017-10-06 22:12:16 +1100
commit265e60a170d0a0ecfc2d20490134ed2c48dd45ab (patch)
treef6af49eeac1812c0d3c1fb563dab67571857bd62 /crypto/dh_helper.c
parent53ecde0b9126ff140abe3aefd7f0ec64d6fa36b0 (diff)
powerpc/64s: Use emergency stack for kernel TM Bad Thing program checks
When using transactional memory (TM), the CPU can be in one of six states as far as TM is concerned, encoded in the Machine State Register (MSR). Certain state transitions are illegal and if attempted trigger a "TM Bad Thing" type program check exception. If we ever hit one of these exceptions it's treated as a bug, ie. we oops, and kill the process and/or panic, depending on configuration. One case where we can trigger a TM Bad Thing, is when returning to userspace after a system call or interrupt, using RFID. When this happens the CPU first restores the user register state, in particular r1 (the stack pointer) and then attempts to update the MSR. However the MSR update is not allowed and so we take the program check with the user register state, but the kernel MSR. This tricks the exception entry code into thinking we have a bad kernel stack pointer, because the MSR says we're coming from the kernel, but r1 is pointing to userspace. To avoid this we instead always switch to the emergency stack if we take a TM Bad Thing from the kernel. That way none of the user register values are used, other than for printing in the oops message. This is the fix for CVE-2017-1000255. Fixes: 5d176f751ee3 ("powerpc: tm: Enable transactional memory (TM) lazily for userspace") Cc: stable@vger.kernel.org # v4.9+ Signed-off-by: Cyril Bur <cyrilbur@gmail.com> [mpe: Rewrite change log & comments, tweak asm slightly] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'crypto/dh_helper.c')
0 files changed, 0 insertions, 0 deletions