DynamoRIO / DynamoRIO/dynamorio

ASSERT in shift_links_to_new_fragment()

Open
#1,894 0 comments 0 reactions 1 assignee Claimed by @byron-hawkins View on GitHub
Bug-Assert OpSys-Windows
Dominant language
C
Stars
3.2k
Forks
629
Avg merge
2d 18h
Merged PRs (30d)
30

Description

When loading several pages full of images in the `jscript9` browser component of Microsoft Office 2013 on Windows 7, a trace head with a far incoming link hits this assert

```
for (l = new_f->in_xlate.incoming_stubs; l != NULL; l = LINKSTUB_NEXT_INCOMING(l)) {
fragment_t *in_f = linkstub_fragment(dcontext, l);
ASSERT(!is_empty_fragment(in_f));
```

The linkstub has flags `0xf930`, i.e.:

```
LINK_JMP
LINK_FAR
LINK_SPECIAL_EXIT
LINK_FRAG_OFFS_AT_END
LINK_END_OF_LIST
LINK_FAKE
LINK_LINKED
LINK_SEPARATE_STUB
```

It seems like this linkstub doesn't belong in the incoming stubs because a comment in `link_fragment_incoming()` says:

```
/* only direct branches are marked on targets' incoming */
ASSERT(LINKSTUB_DIRECT(l->flags));
```

But this fragment is neither `LINK_DIRECT` nor `LINK_INDIRECT`, I suppose because the far jump is handled in IBL. I'm not sure how the linkstub got there.

My build is a couple years old (SVN r2408), since I am in the process of refactoring my security research as a proper DR client, and the easiest way is to start from a clean checkout at the point where I last branched and then move forward. So--if this is an issue in DR itself (and not something I caused)--it may have been fixed already, though I didn't see any issues about it.

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.