linux-kernel - Re: [PATCH v2] ppc64/kprobe: Fix oops when kprobed on 'stdu' instruction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Apr 2017 16:22:18 +0530
From:   Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
To:     Balbir Singh <bsingharora@...il.com>
Cc:     mpe@...erman.id.au, benh@...nel.crashing.org, paulus@...ba.org,
        npiggin@...il.com, aneesh.kumar@...ux.vnet.ibm.com,
        chris@...troguy.com, viro@...iv.linux.org.uk,
        christophe.leroy@....fr, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, anton@...ba.org,
        naveen.n.rao@...ux.vnet.ibm.com,
        Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>,
        "ananth@...ibm.com" <ananth@...ibm.com>
Subject: Re: [PATCH v2] ppc64/kprobe: Fix oops when kprobed on 'stdu'
 instruction

Thanks Balbir for the review,

On Tuesday 11 April 2017 02:25 PM, Balbir Singh wrote:
> On Tue, 2017-04-11 at 10:38 +0530, Ravi Bangoria wrote:
>> If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel 
>> OOPS:
>>
>>   [ 1275.165932] Bad kernel stack pointer cd93c840 at c000000000009868
>>   [ 1275.166378] Oops: Bad kernel stack pointer, sig: 6 [#1]
>>   ...
>>   GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840
>>   ...
>>   [ 1275.178305] NIP [c000000000009868] resume_kernel+0x2c/0x58
>>   [ 1275.178594] LR [c000000000006208] program_check_common+0x108/0x180
>>
>> Basically, on 64 bit system, when user probes on 'stdu' instruction,
>> kernel does not emulate actual store in emulate_step itself because it
>> may corrupt exception frame. So kernel does actual store operation in
>> exception return code i.e. resume_kernel().
>>
>> resume_kernel() loads the saved stack pointer from memory using lwz,
>> effectively loading a corrupt (32bit) address, causing the kernel crash.
>>
>> Fix this by loading the 64bit value instead.
>>
>> Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()") 
>> Signed-off-by: Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
>> Reviewed-by: Naveen N. Rao <naveen.n.rao@...ux.vnet.ibm.com> 
>> ---
> The patch looks correct to me from the description and code. I have not
> validated that the write to GPR1(r1) via store of r8 to 0(r5) is indeed correct.
> I would assume r8 should contain regs->gpr[r1] with the updated ea that
> is written down to the GPR1(r1) which will be what we restore when we return
> from the exception.

emulate_step() updates regs->gpr[r1] with the new value. So,
regs->gpr[r1] and GPR(r1) both are same at resume_kernel.

At resume_kernel, r1 points to the exception frame. Address
of frame preceding exception frame gets loaded in r8 with:

    addi    r8,r1,INT_FRAME_SIZE

Let me know if you need more details.

Ravi