Hi Sean,
On Wed, May 12, 2021 at 05:31:03PM +0000, Sean Christopherson wrote:
> This got me looking at the flows that "inject" #PF, and I'm pretty sure there
> are bugs in __vc_decode_user_insn() + insn_get_effective_ip().
>
> Problem #1: __vc_decode_user_insn() assumes a #PF if insn_fetch_from_user_inatomic()
> fails, but the majority of failure cases in insn_get_seg_base() are #GPs, not #PF.
>
> res = insn_fetch_from_user_inatomic(ctxt->regs, buffer);
> if (!res) {
> ctxt->fi.vector = X86_TRAP_PF;
> ctxt->fi.error_code = X86_PF_INSTR | X86_PF_USER;
> ctxt->fi.cr2 = ctxt->regs->ip;
> return ES_EXCEPTION;
> }
>
> Problem #2: Using '0' as an error code means a legitimate effective IP of '0'
> will be misinterpreted as a failure. Practically speaking, I highly doubt anyone
> will ever actually run code at address 0, but it's technically possible. The
> most robust approach would be to pass a pointer to @ip and return an actual error
> code. Using a non-canonical magic value might also work, but that could run afoul
> of future shenanigans like LAM.
>
> ip = insn_get_effective_ip(regs);
> if (!ip)
> return 0;
Your observations are all correct. I put some changes onto this
patch-set to fix these problems.
Regards,
Joerg
