Dear Andreas, Harald,
I don't really know much about the bit order of TRAU frames but the trau_test.c is causing an out of bounds access to the gsm_fr_map.
Re-produce (GCC >= 3.8 or clang >= 3.2 required):
$ make clean && make CFLAGS+="-ggdb3 -Og -fsanitize=address" $ cd tests/trau $ ./trau_test
Issue: Breakpoint 1, 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0 (gdb) bt #0 0xb69e7810 in __asan_report_error () from /usr/lib/i386-linux-gnu/libasan.so.0 #1 0xb69e08cf in __asan_report_load1 () from /usr/lib/i386-linux-gnu/libasan.so.0 #2 0x0804c4e7 in trau_encode_fr (tf=tf@entry=0xbffff530, data=data@entry=0xbffff700 <incomplete sequence \320>) at trau_mux.c:441 #3 0x08048e06 in test_trau_fr_efr (data=<optimized out>, data@entry=0xbffff700 <incomplete sequence \320>) at trau_test.c:35 #4 0x080494bf in main () at trau_test.c:70 (gdb) frame2 Undefined command: "frame2". Try "help". (gdb) frame 2 #2 0x0804c4e7 in trau_encode_fr (tf=tf@entry=0xbffff530, data=data@entry=0xbffff700 <incomplete sequence \320>) at trau_mux.c:441 441 k = gsm_fr_map[++l]-1; (gdb) p l $1 = 76 (gdb) p l $2 = 76 (gdb) p sizeof(gsm_fr_map) $3 = 76
Please fix as soon as possible as I would like to enable ASAN checking on the jenkins as soon as possible.
kind regards holger
On Wed, May 28, 2014 at 04:58:11PM +0200, Holger Hans Peter Freyther wrote:
Dear Andreas, Harald,
Good Morning,
I don't really know much about the bit order of TRAU frames but the trau_test.c is causing an out of bounds access to the gsm_fr_map.
can one of you please provide a fix for this issue.
thanks holger
Hi Holger,
On Wed, May 28, 2014 at 04:58:11PM +0200, Holger Hans Peter Freyther wrote:
I don't really know much about the bit order of TRAU frames but the trau_test.c is causing an out of bounds access to the gsm_fr_map.
It is the last iteration of the loop, where i==259 and o==260. It is read out-of-bounds but the content is never used. So yes, it is an out-of-bounds access, but one that's unlikely to cause any problems [unless the end of the 'gsm_fr_map' is the edge of the address space]
The only way I can think to avoid it is by putting additional conditionals in the code, which might have performance implications:
Fixed in git: