Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-05-15T05:24:03Zhttps://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/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'https://gitlab.xiph.org/xiph/rav1e/-/issues/76All coefficients forced to zero2018-02-28T19:58:31ZThomas DaedeAll coefficients forced to zero*Created by: barrbrain*
https://github.com/xiph/rav1e/blob/5ffbfe3f5cd12ebd8409b440a01d1cf6947aa978/src/quantize.rs#L22*Created by: barrbrain*
https://github.com/xiph/rav1e/blob/5ffbfe3f5cd12ebd8409b440a01d1cf6947aa978/src/quantize.rs#L22https://gitlab.xiph.org/xiph/rav1e/-/issues/67Frames with show_existing_frame are blank in reconstruction2018-02-28T19:58:32ZThomas DaedeFrames with show_existing_frame are blank in reconstruction*Created by: barrbrain*
Since becced10, frames with show_existing_frame set are blank in the reconstruction stream.*Created by: barrbrain*
Since becced10, frames with show_existing_frame set are blank in the reconstruction stream.https://gitlab.xiph.org/xiph/rav1e/-/issues/44Add partition splitting to RDO2018-09-23T17:20:12ZThomas DaedeAdd partition splitting to RDO*Created by: tmatth*
Currently in `encode_tile` for every superblock, we search for the intra mode with the best RD (based on a 64x64 SSE), for PARTITION_NONE. We should extend this search to one-level of split.*Created by: tmatth*
Currently in `encode_tile` for every superblock, we search for the intra mode with the best RD (based on a 64x64 SSE), for PARTITION_NONE. We should extend this search to one-level of split.https://gitlab.xiph.org/xiph/rav1e/-/issues/37Decoded output not cropped for non-integer multiple of SB size input2018-09-23T17:19:02ZThomas DaedeDecoded output not cropped for non-integer multiple of SB size input*Created by: tmatth*
To reproduce, encode akiyo_qcif.y4m. (176x144)
Reconstructed output:
![rec](https://user-images.githubusercontent.com/66862/35865560-d79ed2d6-0b22-11e8-9a1d-2122a8d6b961.png)
Decoded output:
![dec](https://u...*Created by: tmatth*
To reproduce, encode akiyo_qcif.y4m. (176x144)
Reconstructed output:
![rec](https://user-images.githubusercontent.com/66862/35865560-d79ed2d6-0b22-11e8-9a1d-2122a8d6b961.png)
Decoded output:
![dec](https://user-images.githubusercontent.com/66862/35865582-e48b5ea6-0b22-11e8-91a0-25a18e2dde8b.png)
We need to skip non-visible blocks in `write_sb` (done), change the dimensions that we write in `write_uncompressed_header` (done), change how partitions are coded on the edges of the frame (not started), ~~get all sizes of intra-predictors~~ (not needed since we force 4x4 everywhere).https://gitlab.xiph.org/xiph/rav1e/-/issues/13Encoding 720p park_joy results in garbled decode.2018-02-28T19:58:32ZThomas DaedeEncoding 720p park_joy results in garbled decode.*Created by: gnafuthegreat*
I encoded park_joy_420_720p50.y4m, and then decoded it using the specific git checkout of aom listed in the README. It resulted in this (after being piped to ffmpeg to dump PNGs):
https://themayhaks.c...*Created by: gnafuthegreat*
I encoded park_joy_420_720p50.y4m, and then decoded it using the specific git checkout of aom listed in the README. It resulted in this (after being piped to ffmpeg to dump PNGs):
https://themayhaks.com/~gideon/test-av1-png/
IVF file is here (about 88MB):
https://themayhaks.com/~gideon/test.ivf
I'm not sure if this is just a result of me not resizing to 1280x768 before feeding it to rav1e, but it didn't complain and it seems to have converted it to 1280x768 during the encoding process.https://gitlab.xiph.org/xiph/rav1e/-/issues/28Figure out why cargo rebuilds everything unnecessarily.2018-02-28T19:58:32ZMichael BebenitaFigure out why cargo rebuilds everything unnecessarily.```
cargo run --bin rav1e --release
Compiling rav1e v0.1.0 (file:///Users/.../Workspace/rav1e)
Finished release [optimized] target(s) in 6.98 secs
Running `target/release/rav1e`
```
7s is too long to wait if the code ...```
cargo run --bin rav1e --release
Compiling rav1e v0.1.0 (file:///Users/.../Workspace/rav1e)
Finished release [optimized] target(s) in 6.98 secs
Running `target/release/rav1e`
```
7s is too long to wait if the code hasn't changed.
https://gitlab.xiph.org/xiph/rav1e/-/issues/4Support --help2018-02-28T19:58:32ZThomas DaedeSupport --help*Created by: smarter*
Right now, `cargo run` or `cargo run -- --help` panics.*Created by: smarter*
Right now, `cargo run` or `cargo run -- --help` panics.https://gitlab.xiph.org/xiph/rav1e/-/issues/2Setup Travis for CI2019-11-23T11:07:57ZThomas DaedeSetup Travis for CI*Created by: smarter*
https://docs.travis-ci.com/user/languages/rust/*Created by: smarter*
https://docs.travis-ci.com/user/languages/rust/https://gitlab.xiph.org/xiph/speexdsp/-/issues/1./configure --enable-neon fails on AARCH642023-11-09T05:46:41ZTristan Matthews./configure --enable-neon fails on AARCH64Result:
```
configure: error: No 16 bit type found on this platform!
```
This is probably because configure.ac forces `-march=armv7-a` when `--enable-neon` is given explicitly. Plain old configure works (and detects NEON support) as ex...Result:
```
configure: error: No 16 bit type found on this platform!
```
This is probably because configure.ac forces `-march=armv7-a` when `--enable-neon` is given explicitly. Plain old configure works (and detects NEON support) as expected.https://gitlab.xiph.org/xiph/vorbis/-/issues/2333Infinite loop in _get_prev_page_serial2019-01-28T23:34:17ZStefan LednickyInfinite loop in _get_prev_page_serialWe are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop...We are using libvorbis 1.3.5 , specifically with Unreal Engine.
We get a rare hang in _get_prev_page_serial. What we see is that _get_next_page returns OV_EOF on ln245 of vorbisfile.c, which then causes us to break out of the inner loop. The outer loop then seeks back to the beginning, and starts reading again, until we get the OV_EOF again in the inner loop... repeat infinitely.
OV_EOF, and possibly other error codes, should perhaps also return or be somehow handled so that it doesn't result in an infinite loop. I'm also guessing _get_prev_page has the same issue.https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2228Add per ip cooldown to media.xiph.org captcha2020-05-26T03:38:32ZRalph GilesAdd per ip cooldown to media.xiph.org captchaI noticed this week on https://media.xiph.org/ the same ip address managed to download *through the captcha* the same 89G file 11 times in the same day. That's counting complete transfers, not the POST request or a handful of truncated o...I noticed this week on https://media.xiph.org/ the same ip address managed to download *through the captcha* the same 89G file 11 times in the same day. That's counting complete transfers, not the POST request or a handful of truncated or Range-request downloads.
If possible, I'd like to add a filter to block repeated downloads. Ideally one download per file per ip address, but something less specific would be helpful too. That seems to best way to limit waste like this without slowing down people who actually need multiple resources.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2328When configuration file is invalid, icecast hangs indefinitely2018-06-16T20:30:29ZMarcin LewandowskiWhen configuration file is invalid, icecast hangs indefinitelyI am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to chec...I am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to check if service is running or not, as process exists.
```
/usr/bin/icecast -c /etc/icecast/icecast.xml
/etc/icecast/icecast.xml:1: parser error : Document is empty
FATAL: error parsing config file (/etc/icecast/icecast.xml)
XML config parsing error
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/23272.4.99.1 leaks filedescriptors?2020-02-25T08:58:43ZHugo2.4.99.1 leaks filedescriptors?Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak"....Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak". The server does not respond to new connections anymore, but seems to handle a lot of existing connections still fine. With netstat and lsof a lot of CLOSE_WAIT connections show up:
$ sudo lsof -np 28035 | wc -l
12895
$ sudo lsof -np 28035 | grep CLOSE_WAIT | wc -l
5973
The other 7 servers do not experience this problem (yet). The maximum amount of listeners today was about 6500 per server (on a number of channels).
Could it be that icecast is leaking filedescriptors somehow in situations that are not always triggered (since not all servers encounter this problem)?
All servers are running the same kernel; 4.1.39 and the installation is identical on all systems.
Any suggestions what could be done to debug this problem? It would be nice if we could reproduce this, but I have no clue what could cause this.
Regards,
Hugohttps://gitlab.xiph.org/xiph/ogg/-/issues/2292Granulepos 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/466511c90df23933511eeb891b507af7/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.