DynamoRIO / DynamoRIO/dynamorio

Strange re-relativization after instr_length() then instr_clone()

Open
#2,709 2 comments 0 reactions 0 assignees View on GitHub
Bug-AppFail Component-API Component-IR
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 15h
Merged PRs (30d)
31

Description

In the attached sample, the encoding of a cloned instruction produces an incorrect rip-relative operand--but only when `instr_length()` had been called on the original instruction (prior to cloning). This example uses DR as a standalone encoder/decoder, but I expect the same results in full mode. The sequence of events is:

1. Decode an instruction
2. Call `instr_length()`, which allocates raw bits internally
3. Clone the instruction
4. Encode the clone to a different `final_pc` than the original (decode) location

As shown in the stdout of the sample (quoted below), the rip-relative address in the encoded clone is 0x80 bytes off target. This problem goes away if step 2 is removed, so the presence of valid raw bits is somehow influencing the re-relativization.

Encoded size of xorpd: 8
Original decoded from 0x400000:
xorpd 0x0000000000400200[16byte] %xmm0 -> %xmm0
Original encoded to 0x400100:
xorpd 0x0000000000400200[16byte] %xmm0 -> %xmm0

Clone of decode from 0x400000:
xorpd 0x0000000000400200[16byte] %xmm0 -> %xmm0
Clone encoded to 0x400100:
xorpd 0x0000000000400280[16byte] %xmm0 -> %xmm0 # off target by 0x80

[riprel.tar.gz](https://github.com/DynamoRIO/dynamorio/files/1487724/riprel.tar.gz)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.