Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-08-08T17:46:51Zhttps://gitlab.xiph.org/xiph/liboggz/-/issues/6assertion failure in oggz_close at oggz.c:218 when scanning corrupted file2018-08-08T17:46:51Zkeelerdaassertion failure in oggz_close at oggz.c:218 when scanning corrupted fileoggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/5[liboggz] oggz-info reports incorrect duration for chained files2018-08-08T17:46:39ZGArik[liboggz] oggz-info reports incorrect duration for chained filesHi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrec...Hi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrect. Also slightly different bitrate detection by ogginfo and oggz-info seems strange to me.
Here is an example:
```
lxuser@garik:~/oggz-bug$ ls
test0.ogg test1.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo *.ogg
Processing file "test0.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
Processing file "test1.ogg"...
New logical stream (#1, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 1 ended
lxuser@garik:~/oggz-bug$ oggz-info -a *.ogg
Filename: test0.ogg
Content-Duration: 00:00:55.546
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
------------------------------------------------------------
Filename: test1.ogg
Content-Duration: 00:04:07.520
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
lxuser@garik:~/oggz-bug$ cat test0.ogg test1.ogg > test.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo test.ogg
Processing file "test.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
New logical stream (#2, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 2:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 2 ended
lxuser@garik:~/oggz-bug$ oggz-info -a test.ogg
Content-Duration: 00:04:07.520
Content-Length: 12.356 MB
Content-Bitrate-Average: 418.738 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 64.282 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
```conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/4[liboggz] oggz-diff unable to process files with whitespace in filename2018-08-08T17:45:36ZGArik[liboggz] oggz-diff unable to process files with whitespace in filenameoggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)oggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/liboggz/-/issues/3Buffer overflow in liboggz, httpdate.c, function httpdate_parse2018-08-08T17:44:41ZhannoBuffer overflow in liboggz, httpdate.c, function httpdate_parseThe function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes thi...The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes this.
Also the parser string should limit the size of the month string. See attached patch.
This bug was found with the help of address sanitizer. Can be reproduced by compiling liboggz with -fsanitize=address in CFLAGS+LDFLAGS and running make check.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/liboggz/-/issues/1Granulepos corruption with large/numerous packets (with test case)2018-08-08T17:39:26ZstenyakGranulepos corruption with large/numerous packets (with test case)I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/f6ad965f431dd89127c12fadeddfa357/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2337RFE: Please add a possibility for a relay to transcode the stream2020-11-09T19:35:07Zpetr tomasekRFE: Please add a possibility for a relay to transcode the streamWith Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
...With Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
```xml
<relay>
<server>127.0.0.1</server>
<port>8001</port>
<mount>/example.ogg</mount>
<local-mount>/different.ogg</local-mount>
<on-demand>1</on-demand>
<retry-delay>30</retry-delay>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<transcode-bin>/usr/local/bin/transcodestreamXYZ</transcode-bin>
</relay>
```
Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2336Icecast 2.5.x relays not working2018-07-26T10:19:39ZPhilipp SchafftIcecast 2.5.x relays not workingRelays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Relays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2335`<no-mount>` (`<mount>`'s child) is noop in 2.5.x2021-04-14T10:51:43ZPhilipp Schafft`<no-mount>` (`<mount>`'s child) is noop in 2.5.xThe tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.The tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2333Make playlist generation consistent2020-10-11T16:28:01ZMarvin ScholzMake playlist generation consistentCurrently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!Currently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!https://gitlab.xiph.org/xiph/theora/-/issues/2310Gentoo QA issue with decode.c2018-06-22T17:45:59ZGhost UserGentoo QA issue with decode.cMy GNU/Linux distribution is Gentoo Linux. When installing `media-libs/libtheora-1.1.1-r1` with the Portage package manager I get the following warning message:
```
* QA Notice: Package triggers severe warnings which indicate that it
...My GNU/Linux distribution is Gentoo Linux. When installing `media-libs/libtheora-1.1.1-r1` with the Portage package manager I get the following warning message:
```
* QA Notice: Package triggers severe warnings which indicate that it
* may exhibit random runtime failures.
* /var/tmp/portage/media-libs/libtheora-1.1.1-r1/work/libtheora-1.1.1/lib/decode.c:400:49: warning: iteration 2 invokes undefined behavior [-Waggressive-loop-optimizations]
* Please do not file a Gentoo bug and instead report the above QA
* issues directly to the upstream developers of this software.
* Homepage: https://www.theora.org
```
[build.log.xz](/uploads/fee915344d8156b954b6310b01b7e0e1/build.log.xz)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2331Add history to status-json.xsl2018-07-07T19:19:02ZRoger HågensenAdd history to status-json.xslSince history is now implemented in https://gitlab.xiph.org/xiph/icecast-server/commit/3dd8bdbf40e0988d331724f2a2b5c2bf774584b4 it is hopefully trivial to add this to status-json.xsl as well?Since history is now implemented in https://gitlab.xiph.org/xiph/icecast-server/commit/3dd8bdbf40e0988d331724f2a2b5c2bf774584b4 it is hopefully trivial to add this to status-json.xsl as well?https://gitlab.xiph.org/xiph/icecast-ices/-/issues/2321ices2.0.2 example config missing <yp>2018-10-09T21:06:17ZWaitman Gobbleices2.0.2 example config missing <yp>It would be helpful to have <yp> option and comment in conf/ices-playlist.xml example which ships with 2.0.2.
thanks.It would be helpful to have <yp> option and comment in conf/ices-playlist.xml example which ships with 2.0.2.
thanks.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2322Uncontrolled alloca() in oggenc which may lead to a remote code execution in ...2018-09-17T19:57:06ZJaeseung ChoiUncontrolled alloca() in oggenc which may lead to a remote code execution in 32-bit environmentDuring a fuzz testing, I found a program-crashing bug in the latest version of `oggenc`. When a malicious AIFF audio file is provided as an input, segmentation fault or remote code execution may occur.
I downloaded http://downloads.xiph...During a fuzz testing, I found a program-crashing bug in the latest version of `oggenc`. When a malicious AIFF audio file is provided as an input, segmentation fault or remote code execution may occur.
I downloaded http://downloads.xiph.org/releases/vorbis/vorbis-tools-1.4.0.tar.gz file, and compiled it with clang 3.8.
In `aiff_open()` function of `oggenc/audio.c` file, size argument of alloca() call is not checked tightly, and therefore a large size of memory can be requested.
```
if(!find_aiff_chunk(in, "COMM", &len))
{
fprintf(stderr, _("Warning: No common chunk found in AIFF file\n"));
return 0; /* EOF before COMM chunk */
}
if(len < 18)
{
fprintf(stderr, _("Warning: Truncated common chunk in AIFF header\n"));
return 0; /* Weird common chunk */
}
buffer = alloca(len);
if(fread(buffer,1,len,in) < len)
{
fprintf(stderr, _("Warning: Unexpected EOF in reading AIFF header\n"));
return 0;
}
```
In 64-bit environment, this will simply make the program to crash, but in 32-bit environment this bug can lead to a remote code execution. If a malicious attacker requests a large size of memory (e.g. alloca(0xffffff00)), this will **lift up** the stack pointer (%esp register) instead of correctly allocating a stack buffer. Then, the subsequent fread() call will overwrite the stack and corrupt the saved return address.
I attach the PoC input file to reproduce this bug.
[poc](/uploads/ab90d639d90d2fca08ddbb6e787f8522/poc)
```
jason@debian-stretch:~/ground/vorbis-tools-1.4.0$ gdb oggenc/oggenc -q
Reading symbols from oggenc/oggenc...done.
(gdb) run ~/poc
Starting program: /home/jason/ground/vorbis-tools-1.4.0/oggenc/oggenc ~/poc
Warning: Unexpected EOF in reading AIFF header
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) info reg $eip
eip 0x41414141 0x41414141
```https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2321Segmentation fault in wav_open() function of oggenc2018-05-15T05:24:03ZJaeseung ChoiSegmentation fault in wav_open() function of oggencDuring a fuzz testing, I found a program-crashing bug in the latest version of oggenc. When a malicious WAV file is provided as an input, segmentation fault occurs inside memcpy() called from wav_open().
I downloaded http://downloads.xi...During a fuzz testing, I found a program-crashing bug in the latest version of oggenc. When a malicious WAV file is provided as an input, segmentation fault occurs inside memcpy() called from wav_open().
I downloaded http://downloads.xiph.org/releases/vorbis/vorbis-tools-1.4.0.tar.gz file, and compiled it with clang 3.8.
I attach the PoC file, and GDB/ASAN log.
[poc_segv](/uploads/9bef2ff3b9f9ddc9247cda89fb707000/poc_segv)
[GDB log]
```
jason@debian-amd64-stretch:~/ground/vorbis-tools-1.4.0-clang$ gdb ./oggenc/oggenc -q
Reading symbols from ./oggenc/oggenc...done.
(gdb) run ~/poc_segv
Starting program: /home/jason/ground/vorbis-tools-1.4.0-clang/oggenc/oggenc ~/poc_segv
Warning: INVALID format chunk in wav header.
Trying to read anyway (may not work)...
WARNING: Unknown WAV surround channel mask: -1465341784
blindly mapping speakers using default SMPTE/ITU ordering.
Warning: WAV 'block alignment' value is incorrect, ignoring.
The software that created this file is incorrect.
Program received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:363
363 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) x/i $rip
=> 0x7ffff6f09f4c <__memmove_avx_unaligned_erms+364>: vmovdqu (%rsi),%ymm4
(gdb) info reg rsi
rsi 0x3d0730 3999536
(gdb) where
#0 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:363
#1 0x00000000004055ff in wav_open (in=<optimized out>, opt=<optimized out>, oldbuf=<optimized out>, buflen=<optimized out>) at audio.c:576
#2 0x0000000000405f00 in open_audio_file (in=<optimized out>, opt=<optimized out>) at audio.c:86
#3 0x0000000000404355 in main (argc=<optimized out>, argv=<optimized out>) at oggenc.c:256
```
[ASAN log]
```
jason@debian-amd64-stretch:~/ground/vorbis-tools-1.4.0-ASAN$ export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer
jason@debian-amd64-stretch:~/ground/vorbis-tools-1.4.0-ASAN$ export ASAN_OPTIONS=detect_leaks=0:allocator_may_return_null=1
jason@debian-amd64-stretch:~/ground/vorbis-tools-1.4.0-ASAN$ ./oggenc/oggenc ~/poc_segv
Warning: INVALID format chunk in wav header.
Trying to read anyway (may not work)...
WARNING: Unknown WAV surround channel mask: -1465341784
blindly mapping speakers using default SMPTE/ITU ordering.
Warning: WAV 'block alignment' value is incorrect, ignoring.
The software that created this file is incorrect.
==13504==WARNING: AddressSanitizer failed to allocate 0xffffffffffff84a0 bytes
=================================================================
==13504==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x000000000000,0xffffffffffff84a0) and [0x0000004e2200, 0x0000004da6a0) overlap
#0 0x4a46c2 in __asan_memcpy (/home/jason/ground/vorbis-tools-1.4.0-ASAN/oggenc/oggenc+0x4a46c2)
#1 0x4f506b in wav_open /home/jason/ground/vorbis-tools-1.4.0-ASAN/oggenc/audio.c:576:13
#2 0x4f6c13 in open_audio_file /home/jason/ground/vorbis-tools-1.4.0-ASAN/oggenc/audio.c:86:16
#3 0x4f1495 in main /home/jason/ground/vorbis-tools-1.4.0-ASAN/oggenc/oggenc.c:256:22
#4 0x7ffff65c12e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#5 0x41c689 in _start (/home/jason/ground/vorbis-tools-1.4.0-ASAN/oggenc/oggenc+0x41c689)
AddressSanitizer can not describe address in more detail (wild memory access suspected).
AddressSanitizer can not describe address in more detail (wild memory access suspected).
SUMMARY: AddressSanitizer: memcpy-param-overlap (/home/jason/ground/vorbis-tools-1.4.0-ASAN/oggenc/oggenc+0x4a46c2) in __asan_memcpy
==13504==ABORTING
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2335Four heap buffer overflow(read and write) vuls in function mapping0_forward()...2020-07-16T17:24:00ZJiangxinFour heap buffer overflow(read and write) vuls in function mapping0_forward() of libvorbis-1.3.6, which is caused by lacking of var “channels” check.I found four heap buffer overflow vuls in function mapping0_forward() of libvorbis-1.3.6 by fuzzing libtheora, one of the crash sample behaves as follows, others behave similar:
```
Program received signal SIGABRT, Aborted.
0x00007ffff6...I found four heap buffer overflow vuls in function mapping0_forward() of libvorbis-1.3.6 by fuzzing libtheora, one of the crash sample behaves as follows, others behave similar:
```
Program received signal SIGABRT, Aborted.
0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe1131 in abort () from /lib64/libc.so.6
#2 0x0000000000520a0b in __sanitizer::Abort () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146
#3 0x000000000051eb3a in __sanitizer::Die () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:59
#4 0x00000000005051a5 in ~ScopedInErrorReport (this=<optimized out>, __in_chrg=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:225
#5 __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737488324304, sp=sp@entry=140737488324296, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=<optimized out>, exp@entry=0, fatal=<optimized out>, fatal@entry=true) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:420
#6 0x0000000000505c03 in __asan::__asan_report_load4 (addr=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_rtl.cc:133
#7 0x000000000069fac3 in mapping0_forward (vb=0x7fffffffd330) at mapping0.c:370
#8 0x00000000006244af in vorbis_analysis (vb=0x7fffffffd330, op=0x0) at analysis.c:46
#9 0x000000000052f14e in fetch_and_process_audio (audio=0x616000000380, audiopage=0x7fffffffd5e0, vo=0x7fffffffceb0, vd=0x7fffffffd260, vb=0x7fffffffd330, audioflag=0) at encoder_example.c:996
#10 0x0000000000536546 in main (argc=5, argv=0x7fffffffdfe8) at encoder_example.c:1754
(gdb)
```
These vuls are because of lacking of var “channels” check”, and here is the details of these four vuls in mapping0.c:
vul 1: line 370 of mapping0.c
```
366 for(i=0;i<vi->channels;i++){
367 /* the encoder setup assumes that all the modes used by any
368 specific bitrate tweaking use the same floor */
369
370 int submap=info->chmuxlist[i];//int array[256] oob read, vi->channels need check
```
vul 2: line 614 of mapping0.c
```
612 /* encode floor, compute masking curve, sep out residue */
613 for(i=0;i<vi->channels;i++){
614 int submap=info->chmuxlist[i];//int array[256] oob read, vi->channels need check
615 int *ilogmask=iwork[i];
```
vul 3 and 4: line 666 and 678 of mapping0.c
```
665 for(j=0;j<vi->channels;j++){
666 if(info->chmuxlist[j]==i){//int array[256] oob write, vi->channels need check
667 zerobundle[ch_in_bundle]=0;
668 if(nonzero[j])zerobundle[ch_in_bundle]=1;
669 couple_bundle[ch_in_bundle++]=iwork[j];
670 }
671 }
672
673 classifications=_residue_P[ci->residue_type[resnum]]->
674 class(vb,b->residue[resnum],couple_bundle,zerobundle,ch_in_bundle);
675
676 ch_in_bundle=0;
677 for(j=0;j<vi->channels;j++)
678 if(info->chmuxlist[j]==i)//int array[256] oob write, vi->channels need check
679 couple_bundle[ch_in_bundle++]=iwork[j];
680
681 _residue_P[ci->residue_type[resnum]]->
682 forward(opb,vb,b->residue[resnum],
683 couple_bundle,zerobundle,ch_in_bundle,classifications,i);
```
Note: I need compile libtheora and libvorbis by clang asan and use encoder_example of libtheora to reproduce this vul.
The cmdline to reproduce this vul is like this :
./encoder_example crash_sample xxx.y4m -o out.ogv
The binary encoder_example belongs to libtheora.
recommanded patch : adding on line 238 of mapping0.c
```
230 static int mapping0_forward(vorbis_block *vb){
231 vorbis_dsp_state *vd=vb->vd;
232 vorbis_info *vi=vd->vi;
233 codec_setup_info *ci=vi->codec_setup;
234 private_state *b=vb->vd->backend_state;
235 vorbis_block_internal *vbi=(vorbis_block_internal *)vb->internal;
236 int n=vb->pcmend;
237 int i,j,k;
238 if(vi->channels > MAX_CHANNEL || vi->channels < 0) return -1;//recommanded patch for these vuls
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2334Stack buffer overflow(read) in function bark_noise_hybridmp() of libvorbis-1....2020-07-06T20:52:22ZJiangxinStack buffer overflow(read) in function bark_noise_hybridmp() of libvorbis-1.3.6, which is caused by lacking of array length check.I found a stack buffer overflow vul in function bark_noise_hybridmp() of libvorbis-1.3.6 by fuzzing libtheora, the crash sample behaves as follows:
```
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe...I found a stack buffer overflow vul in function bark_noise_hybridmp() of libvorbis-1.3.6 by fuzzing libtheora, the crash sample behaves as follows:
```
(gdb) bt
#0 0x00007ffff6fdfb55 in raise () from /lib64/libc.so.6
#1 0x00007ffff6fe1131 in abort () from /lib64/libc.so.6
#2 0x0000000000520a0b in __sanitizer::Abort () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cc:146
#3 0x000000000051eb3a in __sanitizer::Die () at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/sanitizer_common/sanitizer_termination.cc:59
#4 0x00000000005051a5 in ~ScopedInErrorReport (this=<optimized out>, __in_chrg=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:225
#5 __asan::ReportGenericError (pc=<optimized out>, bp=bp@entry=140737488322736, sp=sp@entry=140737488322728, addr=<optimized out>, is_write=is_write@entry=false, access_size=access_size@entry=4, exp=<optimized out>, exp@entry=0, fatal=<optimized out>, fatal@entry=true) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_report.cc:420
#6 0x0000000000505c03 in __asan::__asan_report_load4 (addr=<optimized out>) at /home/jiangxin/hunter-tool/llvm5/projects/compiler-rt/lib/asan/asan_rtl.cc:133
#7 0x000000000062cc6d in bark_noise_hybridmp (n=256, b=0x61d000000a80, f=0x61d000007c80, noise=0x619000005a80, offset=140, fixed=-1) at psy.c:608
#8 0x000000000062b3fb in _vp_noisemask (p=0x610000000040, logmdct=0x61d000007c80, logmask=0x619000005a80) at psy.c:705
#9 0x000000000069ff59 in mapping0_forward (vb=0x7fffffffd330) at mapping0.c:417
#10 0x00000000006244af in vorbis_analysis (vb=0x7fffffffd330, op=0x0) at analysis.c:46
#11 0x000000000052f14e in fetch_and_process_audio (audio=0x616000000380, audiopage=0x7fffffffd5e0, vo=0x7fffffffceb0, vd=0x7fffffffd260, vb=0x7fffffffd330, audioflag=0) at encoder_example.c:996
#12 0x0000000000536546 in main (argc=5, argv=0x7fffffffdfe8) at encoder_example.c:1754
```
This vul is because of lacking of array len check , and I recommand a patch as follows:
psy.c:
```
602 for (i = 0, x = 0.f;; i++, x += 1.f) {
603
604 lo = b[i] >> 16;
605 if( lo>=0 ) break;
606 hi = b[i] & 0xffff;
607 if(hi>=n || -lo>=n)break;//recommanded patch for this vul
608 tN = N[hi] + N[-lo];
609 tX = X[hi] - X[-lo];
610 tXX = XX[hi] + XX[-lo];
611 tY = Y[hi] + Y[-lo];
612 tXY = XY[hi] - XY[-lo];
```
Note: I need compile libtheora and libvorbis by clang asan and use encoder_example of libtheora to reproduce this vul.
The cmdline to reproduce this vul is like this :
./encoder_example crash_sample xxx.y4m -o out.ogv
The binary encoder_example belongs to libtheora.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2330Segmentation Fault in auth.c2018-04-18T00:14:17ZMarvin ScholzSegmentation Fault in auth.cReported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server...Reported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server that is actually running (the stream must have parameter hidden=0 and fallback-override=1)
2. Start Icecast
3. Stream to Icecast, and then stop the stream after an arbitrary amount of time
4. Load the status page in the browser
At that point, there will be a seg fault as described above. It does not happen when the mount point is hidden for some reason.
Test system is running Debian 9.3. Icecast version 2.4.99.2https://gitlab.xiph.org/xiph/icecast-server/-/issues/2329Config file using url auth causes SIGILL on SIGHUP2018-09-28T13:17:37ZMarvin ScholzConfig file using url auth causes SIGILL on SIGHUPReported by spr0cketeer on 21 Nov 2017 (Github):
Hello icecasters!
Using icecast master cd0a3f9
getting a SIGILL when sending a SIGHUP to reread config file.
Only happens when using url auth:
```
<mount> ...Reported by spr0cketeer on 21 Nov 2017 (Github):
Hello icecasters!
Using icecast master cd0a3f9
getting a SIGILL when sending a SIGHUP to reread config file.
Only happens when using url auth:
```
<mount>
<mount-name>/test</mount-name>
<authentication type="url">
<option name="listener_add" value="http://example.com/auth"/>
</authentication>
</mount>
```
Server is running on haswell architecture - related: karlheyes/icecast-kh#157
```
Thread 1 "icecast" received signal SIGHUP, Hangup.
[2017-11-20 23:02:55] INFO sighandler/_sig_hup Caught signal 1, scheduling config re-read...
[2017-11-20 23:02:55] INFO auth_url/auth_get_url_auth URL based authentication setup
[New Thread 0x7fffeebd4700 (LWP 9495)]
[2017-11-20 23:02:55] INFO auth/auth_run_thread Authentication thread started
[2017-11-20 23:02:55] WARN CONFIG/__check_hostname Warning, <hostname> not configured, using default value "localhost". This will cause problems, e.g. this breaks YP directory listings. YP directory listing support will be disabled.
[2017-11-20 23:02:55] WARN CONFIG/_parse_root Warning, <location> not configured, using default value "Earth".
[2017-11-20 23:02:55] WARN CONFIG/_parse_root Warning, <admin> contact not configured, using default value "icemaster@localhost". This breaks YP directory listings. YP directory support will be disabled.
[2017-11-20 23:02:55] INFO auth/auth_run_thread Authentication thread shutting down
[2017-11-20 23:02:55] INFO auth_url/auth_url_clear Doing auth URL cleanup
[2017-11-20 23:02:55] INFO connection/get_tls_certificate No TLS capability on any configured ports
[Thread 0x7ffff7fba700 (LWP 8767) exited]
Thread 5 "icecast" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffeecd6700 (LWP 8770)]
__GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
38 pthread_rwlock_unlock.c: No such file or directory.
(gdb) bt
#0 __GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
#1 0x000000000042ac25 in thread_rwlock_unlock_c (rwlock=rwlock@entry=0x642800 <_locks>, line=line@entry=754, file=file@entry=0x42fe9f "cfgfile.c") at thread.c:568
#2 0x000000000040b66c in config_release_config () at cfgfile.c:754
#3 config_reread_config () at cfgfile.c:701
#4 0x0000000000411025 in _slave_thread (arg=arg@entry=0x0) at slave.c:751
#5 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#6 0x00007ffff68546ba in start_thread (arg=0x7fffeecd6700) at pthread_create.c:333
#7 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) thread apply all bt
Thread 7 (Thread 0x7fffeebd4700 (LWP 9495)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=150000) at thread.c:626
#2 0x000000000042304a in auth_run_thread (arg=arg@entry=0x7fffd800b490) at auth.c:359
#3 0x000000000042a6cd in _start_routine (arg=0x7fffd800bce0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7fffeebd4700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 6 (Thread 0x7fffeec55700 (LWP 8771)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=150000) at thread.c:626
#2 0x0000000000421183 in event_run_thread (arg=arg@entry=0x0) at event.c:174
#3 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7fffeec55700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7fffeecd6700 (LWP 8770)):
#0 __GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
#1 0x000000000042ac25 in thread_rwlock_unlock_c (rwlock=rwlock@entry=0x642800 <_locks>, line=line@entry=754, file=file@entry=0x42fe9f "cfgfile.c") at thread.c:568
#2 0x000000000040b66c in config_release_config () at cfgfile.c:754
#3 config_reread_config () at cfgfile.c:701
#4 0x0000000000411025 in _slave_thread (arg=arg@entry=0x0) at slave.c:751
#5 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#6 0x00007ffff68546ba in start_thread (arg=0x7fffeecd6700) at pthread_create.c:333
#7 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7ffff7eb8700 (LWP 8769)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=200000) at thread.c:626
#2 0x0000000000428afd in yp_update_thread (arg=arg@entry=0x0) at yp.c:732
#3 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7ffff7eb8700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7ffff7f39700 (LWP 8768)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=300000) at thread.c:626
#2 0x000000000041556e in _stats_thread (arg=arg@entry=0x0) at stats.c:737
#3 0x000000000042a6cd in _start_routine (arg=0x68f160) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7ffff7f39700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7ffff7fbc740 (LWP 8763)):
#0 0x00007ffff657e70d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000040c6ee in poll (__timeout=300, __nfds=<optimised out>, __fds=0x7fffffffa450) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 wait_for_serversock (timeout=300) at connection.c:302
#3 _accept_connection (duration=300) at connection.c:371
#4 connection_accept_loop () at connection.c:616
#5 0x000000000040685a in _server_proc () at main.c:356
#6 main (argc=<optimised out>, argv=<optimised out>) at main.c:601
```https://gitlab.xiph.org/xiph/speex/-/issues/2038integer overflow leads to out-of-bounds read in print_comments(char *comments...2022-05-07T17:59:07ZJayZhanginteger overflow leads to out-of-bounds read in print_comments(char *comments, int length)Hi,
recently I fuzzed speex-1.2.0 with afl,and found a crash:
root@host-10-0-0-25:/home/ubuntu/speex/test/speex-1.2.0# src/speexdec fuzzout/crashes/id:000000,sig:06,src:000001,op:flip2,pos:168 dddd.wav 2>redirect_stderr
1. The origin...Hi,
recently I fuzzed speex-1.2.0 with afl,and found a crash:
root@host-10-0-0-25:/home/ubuntu/speex/test/speex-1.2.0# src/speexdec fuzzout/crashes/id:000000,sig:06,src:000001,op:flip2,pos:168 dddd.wav 2>redirect_stderr
1. The original normal speex file is:[all_normal.spx](/uploads/95cfb92204df8079a4557dd4a4cde109/all_normal.spx)
1. The invalid speex file generated by afl is:[id_000000_sig_06_src_000001_op_flip2_pos_168](/uploads/3a854323ea911329d17ae84dc8bfc7e0/id_000000_sig_06_src_000001_op_flip2_pos_168)
1. And the stderr is:[redirect_stderr](/uploads/3fc6e869a76e21c734b11928010ae313/redirect_stderr)
later I analyzed the crash, and found there is a integer overflow in function print_comments():
Breakpoint 9, print_comments (
comments=0xf6000200 "=r\230\023\361\063~\375\234Y\220}\r\035\221q5\027\241\026", <incomplete sequence \331>, length=0x3e) at speexdec.c:107
107 c+=4;
gdb-peda$ print len
$105 = 0x1398723d
gdb-peda$ print end
$106 = 0xf600023e
Obviously,c=comments+4,c+len<end, and bypass the length check at line 108 in speexdec.c,then leads to out-of-bounds read at line 113 in speexdec.c.Tristan MatthewsTristan Matthewshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2299libshout with OpenSSL 1.1.02020-11-15T04:54:25Zmark burdettlibshout with OpenSSL 1.1.0tlschenkjr wrote @ https://github.com/xiph/Icecast-libshout/issues/7
> libshout contains calls to deprecated functions in openssl 1.1.0 and fails to build correctly. Any chance of that getting updated?
The error is: undefined reference...tlschenkjr wrote @ https://github.com/xiph/Icecast-libshout/issues/7
> libshout contains calls to deprecated functions in openssl 1.1.0 and fails to build correctly. Any chance of that getting updated?
The error is: undefined reference to `SSLeay_add_all_algorithms'