Skip to content

Commit

Permalink
Fix integer overflow in fuzzed dwarf rendering in graphs ##crash
Browse files Browse the repository at this point in the history
* Reported by @solid-snail via huntrdev
* BountyID: c6f8d3ef-5420-4eba-9a5f-aba5e2b5fea2/
* Reproducer: `intof_mod`
  • Loading branch information
radare committed Dec 1, 2022
1 parent 7ef58be commit b53a158
Show file tree
Hide file tree
Showing 2 changed files with 7 additions and 0 deletions.
3 changes: 3 additions & 0 deletions dist/docker/Dockerfile
Expand Up @@ -70,6 +70,9 @@ RUN DEBIAN_FRONTEND=noninteractive dpkg --add-architecture i386 && \
bison \
pkg-config \
make \
python3 \
python3-pip \
sudo \
glib-2.0 \
libc6:i386 \
libncurses5:i386 \
Expand Down
4 changes: 4 additions & 0 deletions libr/core/canal.c
Expand Up @@ -1390,6 +1390,10 @@ static char *core_anal_graph_label(RCore *core, RAnalBlock *bb, int opts) {
filestr = r_file_slurp_line (file, line, 0);
if (filestr) {
int flen = strlen (filestr);
if (idx < 0 || ST32_ADD_OVFCHK (idx, flen + 8)) {
R_LOG_WARN ("integer overflow detected");
break;
}
cmdstr = realloc (cmdstr, idx + flen + 8);
memcpy (cmdstr + idx, filestr, flen);
idx += flen;
Expand Down

1 comment on commit b53a158

@solid-snail
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think theoretically flen could already be overflowed at that point.
If I recall correctly, when I tried testing with source line of that length (2~4 GB) I had crashes earlier on in the startup process, so I couldn't validate it.
Might be worth using a different type for flen and idx (the 64bit unsigned counterpart), using pointers to track the locations, or limiting line length (or checking for overflow) in the line slurping process.

Please sign in to comment.