• Paul Mackerras's avatar
    powerpc: Fix kernel crash in emulation of vector loads and stores · 4716e488
    Paul Mackerras authored
    Commit 350779a2 ("powerpc: Handle most loads and stores in
    instruction emulation code", 2017-08-30) changed the register usage
    in get_vr and put_vr with the aim of leaving the register number in
    r3 untouched on return.  Unfortunately, r6 was not a good choice, as
    the callers as of 350779a2 store a MSR value in r6.  Then, in
    commit c22435a5 ("powerpc: Emulate FP/vector/VSX loads/stores
    correctly when regs not live", 2017-08-30), the saving and restoring
    of the MSR got moved into get_vr and put_vr.  Either way, the effect
    is that we put a value in MSR that only has the 0x3f8 bits non-zero,
    meaning that we are switching to 32-bit mode.  That leads to a crash
    like this:
    
    Unable to handle kernel paging request for instruction fetch
    Faulting instruction address: 0x0007bea0
    Oops: Kernel access of bad area, sig: 11 [#12]
    LE SMP NR_CPUS=2048 NUMA PowerNV
    Modules linked in: vmx_crypto binfmt_misc ip_tables x_tables autofs4 crc32c_vpmsum
    CPU: 6 PID: 32659 Comm: trashy_testcase Tainted: G      D         4.13.0-rc2-00313-gf3026f57e6ed-dirty #23
    task: c000000f1bb9e780 task.stack: c000000f1ba98000
    NIP:  000000000007bea0 LR: c00000000007b054 CTR: c00000000007be70
    REGS: c000000f1ba9b960 TRAP: 0400   Tainted: G      D          (4.13.0-rc2-00313-gf3026f57e6ed-dirty)
    MSR:  10000000400010a1 <HV,ME,IR,LE>  CR: 48000228  XER: 00000000
    CFAR: c00000000007be74 SOFTE: 1
    GPR00: c00000000007b054 c000000f1ba9bbe0 c000000000e6e000 000000000000001d
    GPR04: c000000f1ba9bc00 c00000000007be70 00000000000000e8 9000000002009033
    GPR08: 0000000002000000 100000000282f033 000000000b0a0900 0000000000001009
    GPR12: 0000000000000000 c00000000fd42100 0706050303020100 a5a5a5a5a5a5a5a5
    GPR16: 2e2e2e2e2e2de70c 2e2e2e2e2e2e2e2d 0000000000ff00ff 0606040202020000
    GPR20: 000000000000005b ffffffffffffffff 0000000003020100 0000000000000000
    GPR24: c000000f1ab90020 c000000f1ba9bc00 0000000000000001 0000000000000001
    GPR28: c000000f1ba9bc90 c000000f1ba9bea0 000000000b0a0908 0000000000000001
    NIP [000000000007bea0] 0x7bea0
    LR [c00000000007b054] emulate_loadstore+0x1044/0x1280
    Call Trace:
    [c000000f1ba9bbe0] [c000000000076b80] analyse_instr+0x60/0x34f0 (unreliable)
    [c000000f1ba9bc70] [c00000000007b7ec] emulate_step+0x23c/0x544
    [c000000f1ba9bce0] [c000000000053424] arch_uprobe_skip_sstep+0x24/0x40
    [c000000f1ba9bd00] [c00000000024b2f8] uprobe_notify_resume+0x598/0xba0
    [c000000f1ba9be00] [c00000000001c284] do_notify_resume+0xd4/0xf0
    [c000000f1ba9be30] [c00000000000bd44] ret_from_except_lite+0x70/0x74
    Instruction dump:
    XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
    XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
    ---[ end trace a7ae7a7f3e0256b5 ]---
    
    To fix this, we just revert to using r3 as before, since the callers
    don't rely on r3 being left unmodified.
    
    Fortunately, this can't be triggered by a misaligned load or store,
    because vector loads and stores truncate misaligned addresses rather
    than taking an alignment interrupt.  It can be triggered using
    uprobes.
    
    Fixes: 350779a2 ("powerpc: Handle most loads and stores in instruction emulation code")
    Reported-by: default avatarAnton Blanchard <anton@ozlabs.org>
    Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
    Tested-by: default avatarAnton Blanchard <anton@samba.org>
    Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
    4716e488
ldstfp.S 3.93 KB