root@d8a714203f6e:/path_to_gpac/build/bin# ./MP4Box -hint -out /dev/null poc
[iso file] Unknown box type t8Aak in parent moov
[iso file] Box "UNKN" is larger than container box
[iso file] Box "moov" size 211 (start 20) invalid (read 2209)
[iso file] Box "nmhd" (start 359) has 8 extra bytes
[iso file] Unknown box type dreu in parent dinf
[iso file] Box "UNKN" is larger than container box
[iso file] Missing dref box in dinf
[iso file] Box "dinf" size 36 (start 379) invalid (read 64)
[iso file] Unknown box type url in parent srpp
[iso file] Unknown box type srpp in parent srpp
[iso file] Box "UNKN" is larger than container box
[iso file] Box "srpp" size 1814 (start 415) invalid (read 1854)
[iso file] Unknown box type dre- in parent dinf
[iso file] Box "UNKN" is larger than container box
[iso file] Missing dref box in dinf
[iso file] Box "dinf" size 36 (start 2229) invalid (read 64)
[isom] invalid tag size in Xtra !
[isom] invalid tag size in Xtra !
[isom] not enough bytes in box Xtra: 46 left, reading 1836070003 (file isomedia/box_code_base.c, line 12754), skipping box
[iso file] Box "Xtra" (start 2265) has 60 extra bytes
[iso file] Unknown top-level box type 00000001
0.500 secs Interleaving
utils/bitstream.c:1053:6: runtime error: null pointer passed as argument 2, which is declared to never be null
Here is the trace reported by debugging. We can see that the memcpy function is called on line 1053 of utils/bitstream.c, which will copy the contents of the second parameter data to the buffer pointed to by the first parameter. Unfortunately, in this trace the data is 0 (NULL), causing the program to crash.
In file: /path_to_gpac/src/utils/bitstream.c
1048 case GF_BITSTREAM_FILE_READ:
1049 case GF_BITSTREAM_FILE_WRITE:
1050 if (bs->cache_write) {
1051 //if block fits in our write cache, write it
1052 if (bs->buffer_written + nbBytes < bs->cache_write_size) {
► 1053 memcpy(bs->cache_write+bs->buffer_written, data, nbBytes);
1054 bs->buffer_written+=nbBytes;
1055 return nbBytes;
1056 }
1057 //otherwise flush cache and use file write
1058 bs_flush_write_cache(bs);
pwndbg> backtrace
#0 gf_bs_write_data (bs=0x60f00000dc90, data=0x0, nbBytes=1) at utils/bitstream.c:1053
#1 0x00007ff9797a8f82 in xtra_box_write (s=0x60400000d590, bs=0x60f00000dc90) at isomedia/box_code_base.c:12814
#2 0x00007ff979816fb8 in gf_isom_box_write_listing (a=0x60400000d590, bs=0x60f00000dc90) at isomedia/box_funcs.c:1834
#3 0x00007ff979817737 in gf_isom_box_write (a=0x60400000d590, bs=0x60f00000dc90) at isomedia/box_funcs.c:1883
#4 0x00007ff9798b432c in WriteInterleaved (mw=0x7ffd2b3ab870, bs=0x60f00000dc90, drift_inter=GF_TRUE) at isomedia/isom_store.c:1963
#5 0x00007ff9798bb1ca in WriteToFile (movie=0x616000009c80, for_fragments=GF_FALSE) at isomedia/isom_store.c:2549
#6 0x00007ff9798574d1 in gf_isom_write (movie=0x616000009c80) at isomedia/isom_read.c:600
#7 0x00007ff979857a3f in gf_isom_close (movie=0x616000009c80) at isomedia/isom_read.c:624
#8 0x00000000004413cc in mp4boxMain (argc=5, argv=0x7ffd2b3b0478) at main.c:6547
#9 0x00000000004416f2 in main (argc=5, argv=0x7ffd2b3b0478) at main.c:6601
#10 0x00007ff975d2e840 in __libc_start_main (main=0x4416d2 <main>, argc=5, argv=0x7ffd2b3b0478, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd2b3b0468) at ../csu/libc-start.c:291
#11 0x000000000040fd09 in _start ()
I tracked the null assignment of data in isomedia/box_code_base.c. data2 is initialized to NULL in line 12743. When the value of prop_size is greater than 4 ( line 12764 ), the program will allocate a memory chunk to data2 ( line 12769 ). Otherwise, data2 will remain NULL and will be assigned to tag->prop_value in line 12777.
In my crash, prop_size was set to 1 causing tag->prop_value to be NULL. The tag is then added to ptr->tags for subsequent access ( line 12779).
When the program executes to xtra_box_write, it will get a tag from ptr->tags ( line 12801 ), and pass tag->prop_value to the second parameter of gf_bs_write_data ( line 12814 ), which eventually results in data being NULL.
Although the program judges whether tag->prop_value is 0 in line 12805, it does not change the execution flow of the program and the value of tag->prop_value.
version info:
poc: poc$poc$
command: MP4Box -hint -out /dev/null
crash:
Here is the trace reported by debugging. We can see that the
memcpyfunction is called on line 1053 ofutils/bitstream.c, which will copy the contents of the second parameterdatato the buffer pointed to by the first parameter. Unfortunately, in this trace thedatais 0 (NULL), causing the program to crash.I tracked the null assignment of
datainisomedia/box_code_base.c.data2is initialized to NULL in line 12743. When the value ofprop_sizeis greater than 4 ( line 12764 ), the program will allocate a memory chunk todata2( line 12769 ). Otherwise,data2will remain NULL and will be assigned totag->prop_valuein line 12777.In my crash,
prop_sizewas set to 1 causingtag->prop_valueto be NULL. Thetagis then added toptr->tagsfor subsequent access ( line 12779).https://github.com/gpac/gpac/blob/5d68ccd1fa4a5a76cf8db31a33cfb4a2fe2bd4ad/src/isomedia/box_code_base.c#L12736-L12786
When the program executes to
xtra_box_write, it will get atagfromptr->tags( line 12801 ), and passtag->prop_valueto the second parameter ofgf_bs_write_data( line 12814 ), which eventually results indatabeing NULL.Although the program judges whether
tag->prop_valueis 0 in line 12805, it does not change the execution flow of the program and the value oftag->prop_value.https://github.com/gpac/gpac/blob/5d68ccd1fa4a5a76cf8db31a33cfb4a2fe2bd4ad/src/isomedia/box_code_base.c#L12791-L12817
Hope my analysis will help.
The text was updated successfully, but these errors were encountered: