Issue 87 in xar: data corruption in on Linux/glibc-based systems.

[codesite...@google.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 87 by HinTak.L...@gmail.com: data corruption in on
Linux/glibc-based systems.
https://code.google.com/p/xar/issues/detail?id=87

While trying to decompress and extract files from an apple installer
manually on linux, I encountered inconsistent behaviors and data
corruptions for the downstream LZMA decompression. After spending almost a
day on it, I found the answer with valgrind. Here is the patch:

==========
diff --git a/xar/lib/io.c b/xar/lib/io.c
index 8d2f56e..37d0276 100644
--- a/xar/lib/io.c
+++ b/xar/lib/io.c
@@ -608,7 +608,7 @@ static int32_t flush_stream(xar_stream *stream) {
state->pending_buf = NULL;
} else if( state->pending_buf_size > len ) {
state->pending_buf_size -= len;
- memcpy(state->pending_buf, state->pending_buf +
len, state->pending_buf_size);
+ memmove(state->pending_buf, state->pending_buf +
len, state->pending_buf_size);
}
}

==========

The original code is obviously wrong as memcpy should not be used to copy
overlapping regions. It is
possible in the above code path if "state->pending_buf_size > len" even
after -=len .
This depends on the memcpy implementation, and does not seem to affect mac
os X, but certainly affect Linux/glibc.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings