Injected mprotect system call into traced process fails with EFAULT

Question

I'm injecting an mprotect call into a traced process:

static int inject_mprotect(pid_t child, void *addr, size_t len, int prot)
{
    // Machine code:
    //  int $0x80       (system call)
    //  int3            (trap)
    char code[] = {0xcd,0x80,0xcc,0};
    char orig_code[3];
    struct user_regs_struct regs;
    struct user_regs_struct orig_regs;

    // Take a copy of current state
    __check_ptrace(PTRACE_GETREGS, child, NULL, &orig_regs);
    getdata(child, INSTRUCTION_POINTER(regs), orig_code, 3);

    // Inject the code, update registers
    putdata(child, INSTRUCTION_POINTER(regs), code, 3);
    __check_ptrace(PTRACE_GETREGS, child, NULL, &regs);
    XAX_REGISTER(regs) = MPROTECT_SYSCALL;
    MPROTECT_ARG_START(regs) = (unsigned long)addr;
    MPROTECT_ARG_LEN(regs) = len;
    MPROTECT_ARG_PROT(regs) = prot;   
    __check_ptrace(PTRACE_SETREGS, child, NULL, &regs);

    // Snip

However the call fails, returning -14 (EFAULT). I've looked through the mprotect source (kernel 3.13) and can't see why my system call would return this.

If I trace my injected call and print out the registers I see the following:

SIGTRAP: eip: 0x34646ef8d4, syscall 10, rc = -38
PARENT 10 MPROTECT(start: 0x00007f45b9611000, len: 4096, prot: 0)
EIP: 0x00000034646ef8d4 AX: 0xffffffffffffffda  BX: 0x0000000000000005  CX: 0xffffffffffffffff
 DX: 0x0000000000000000 DI: 0x00007f45b9611000  BP: 0x00007fffcb93bc20  SI: 0x0000000000001000
 R8: 0x0000000000000000 R9: 0x0000000000000000  R10: 0x0000000000000000
SIGTRAP: eip: 0x34646ef8d4, syscall 10, rc = -14 Bad address (trap after system call exit)

To validate the system call format I added an mprotect call to the child and dumped out its arguments and registers:

SIGTRAP: eip: 0x34646ef927, syscall 10, rc = -38
CHILD  10 MPROTECT(start: 0x00007f45b9611000, len: 4096, prot: 0)
EIP: 0x00000034646ef927 AX: 0xffffffffffffffda  BX: 0x0000000000000005  CX: 0xffffffffffffffff
 DX: 0x0000000000000000 DI: 0x00007f45b9611000  BP: 0x00007fffcb93bc20  SI: 0x0000000000001000
 R8: 0x000000000000004e R9: 0x746f72706d206c6c  R10: 0x00007fffcb93b9a0
SIGTRAP (child return): eip: 0x34646ef927, syscall 10, rc = 0

The call from the child succeeds. So given that I'm making the same system call (10) with the same arguments, why does the injected call fail with EFAULT while a call from the child is successful?

The only difference between the calls is some junk in regs.r8, regs.r9 and regs.r10, however based this table of system calls on X86_64 I don't believe the contents of those registers would affect the system call.

Just a wild guess: Maybe this is related to [this](http://stackoverflow.com/questions/8510333/x86-64-assembly-linux-system-call-confusion) question? (Curious, because your link says that syscall 10 is 64bit mprotect, but `int 0x80` is 32bit syntax) — Phillip, Jun 02 '14 at 13:48
@Phillip thanks that sounds very promising - been focussed on making the system call itself and the arguments architecture independent that I didn't think about `int 0x80` vs `syscall`! — Chiggs, Jun 02 '14 at 14:20
@Phillip you were right, it was because I was using the 32-bit system call. This is now resolved and I've pushed my working code to [github](https://github.com/potentialventures/cocotb/commit/d85ee802248395547ef51aef8c37f3837ab32811). Can you post an answer so I can accept it? — Chiggs, Jun 02 '14 at 19:05
Great, done. (And thanks for the link. Both the overall project and your mmap trap look quite interesting.) — Phillip, Jun 03 '14 at 06:29

score 4 · Accepted Answer · edited May 23 '17 at 12:27

The problem is related to this question: i386 and x86_64 use different calling conventions for system calls. Your example code uses int 0x80, the i386 variant, but syscall_number = 10, the 64-bit syscall number for mprotect. In 32-bit environments, syscall 10 coresponds to unlink, according to this list, which can return EFAULT (Bad address).

On 64-bit platforms, using either the 32-bit or 64-bit variant in a consistent manner solves the problem.

Injected mprotect system call into traced process fails with EFAULT

1 Answers1