Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-09-23T17:20:12Zhttps://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/31Enable rustfmt checking locally and on Travis-ci2018-02-28T19:58:32ZMichael BebenitaEnable rustfmt checking locally and on Travis-cihttps://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/3Add a mode to test encode/decode mismatch2018-02-28T19:58:32ZThomas DaedeAdd a mode to test encode/decode mismatch*Created by: smarter*
Probably by relying on aomdec being on the PATH*Created by: smarter*
Probably by relying on aomdec being on the PATHhttps://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.https://gitlab.xiph.org/xiph/vorbis/-/issues/2332CVE-2017-11333 - The vorbis_analysis_wrote function in lib/block.c in Xiph.Or...2018-03-17T18:07:32ZGuido GüntherCVE-2017-11333 - The vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 allows remote attackers to cause a denial of service (OOM) via a crafted wav file.Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
1.
the vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(OOM) via a ...Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
1.
the vorbis_analysis_wrote function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(OOM) via a
crafted wav file.
I found this bug when I test Sound eXchange(SoX) 14.4.2 which used the libvorbis library.
./sox libvorbis_1.3.5_OOM.wav out.ogg
/var/log/syslog info:
Jul 13 19:58:05 ubuntu kernel: [] Out of memory: Kill process 44203 (sox) score 364 or sacrifice child
Jul 13 19:58:05 ubuntu kernel: [] Killed process 44203 (sox) total-vm:1831804kB, anon-rss:599932kB, file-rss:40kB
----debug info:----
#0 0x00007ffff5df5e92 in vorbis_analysis_wrote ()
from /usr/local/lib/libvorbis.so.0
#1 0x00007ffff7ba1cba in write_samples (ft=0x611c20, buf=buf@entry=0x0,
len=len@entry=0x0) at vorbis.c:358
#2 0x00007ffff7ba1dc5 in stopwrite (ft=<optimized out>) at vorbis.c:398
#3 0x00007ffff7b58488 in sox_close (ft=0x611c20) at formats.c:1006
#4 0x0000000000405fa8 in cleanup () at sox.c:246
#5 0x0000000000403479 in main (argc=argc@entry=0x3,
argv=argv@entry=0x7fffffffe5e8) at sox.c:3050
#6 0x00007ffff727bec5 in __libc_start_main (main=0x4029c0 <main>, argc=0x3,
argv=0x7fffffffe5e8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe5d8) at libc-start.c:287
#7 0x0000000000403c65 in _start ()
--------
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2331CVE-2017-11735 - The vorbis_block_clear function in lib/block.c in Xiph.Org l...2017-10-09T06:14:10ZGuido GüntherCVE-2017-11735 - The vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via a crafted ogg file.Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
2.
the vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(NULL pointer ...Discovered by qflb.wu
See 2nd issue in http://seclists.org/fulldisclosure/2017/Jul/82
Copy paste from there:
```
2.
the vorbis_block_clear function in lib/block.c in Xiph.Org libvorbis 1.3.5 can cause a denial of service(NULL pointer
dereference and application crash) via a crafted ogg file.
I found this bug when I test mp3splt 2.6.2 which used the libvorbis library.
./mp3splt -P -t 0.9 libvorbis_1.3.5_null_pointer_dereference.ogg
----debug info:----
0x00007ffff61752c0 in vorbis_block_clear () from /usr/local/lib/libvorbis.so.0
(gdb) disassemble
Dump of assembler code for function vorbis_block_clear:
0x00007ffff61752a0 <+0>:push %r14
0x00007ffff61752a2 <+2>:mov %rdi,%r14
0x00007ffff61752a5 <+5>:push %r13
0x00007ffff61752a7 <+7>:push %r12
0x00007ffff61752a9 <+9>:push %rbp
0x00007ffff61752aa <+10>:push %rbx
0x00007ffff61752ab <+11>:mov 0xb8(%rdi),%r13
0x00007ffff61752b2 <+18>:callq 0x7ffff616b240 <_vorbis_block_ripcord@plt>
0x00007ffff61752b7 <+23>:mov 0x70(%r14),%rdi
0x00007ffff61752bb <+27>:test %rdi,%rdi
0x00007ffff61752be <+30>:je 0x7ffff61752c5 <vorbis_block_clear+37>
=> 0x00007ffff61752c0 <+32>:callq 0x7ffff616b130 <free@plt>
0x00007ffff61752c5 <+37>:test %r13,%r13
0x00007ffff61752c8 <+40>:je 0x7ffff617530c <vorbis_block_clear+108>
0x00007ffff61752ca <+42>:mov $0x1,%r12d
0x00007ffff61752d0 <+48>:xor %ebx,%ebx
0x00007ffff61752d2 <+50>:jmp 0x7ffff61752df <vorbis_block_clear+63>
0x00007ffff61752d4 <+52>:nopl 0x0(%rax)
0x00007ffff61752d8 <+56>:add $0x1,%ebx
0x00007ffff61752db <+59>:add $0x1,%r12d
0x00007ffff61752df <+63>:movslq %ebx,%rax
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) i r
rax 0x22
rbx 0x61fca06421664
rcx 0x00
rdx 0x7ffff7ba6778140737349576568
rsi 0x00
rdi 0x80128
rbp 0x7fffffffd4700x7fffffffd470
rsp 0x7fffffffd4000x7fffffffd400
r8 0x746e656d75636f008389754676633104128
r9 0x6143506374224
r10 0x7fffffffd1f0140737488343536
r11 0x7ffff61752a0140737322111648
r12 0x6128506367312
r13 0x00
r14 0x6205606423904
r15 0x7ffff7bcf146140737349742918
rip 0x7ffff61752c00x7ffff61752c0 <vorbis_block_clear+32>
eflags 0x202[ IF ]
cs 0x3351
ss 0x2b43
ds 0x00
es 0x00
fs 0x00
---Type <return> to continue, or q <return> to quit---
gs 0x00
(gdb) ni
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x80) at malloc.c:2929
2929malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x80) at malloc.c:2929
#1 0x00007ffff61752c5 in vorbis_block_clear ()
from /usr/local/lib/libvorbis.so.0
#2 0x00007ffff65ac5ae in splt_ogg_v_free (oggstate=0x61fca0) at ogg.c:162
#3 0x00007ffff65ace0b in splt_ogg_info (in=<optimized out>,
state=state@entry=0x60ddb0, error=error@entry=0x7fffffffdbf0) at ogg.c:545
#4 0x00007ffff65acf75 in splt_ogg_get_info (state=state@entry=0x60ddb0,
file_input=<optimized out>, error=error@entry=0x7fffffffdbf0) at ogg.c:108
#5 0x00007ffff65ae6c7 in splt_pl_init (state=0x60ddb0, error=0x7fffffffdbf0)
at ogg.c:1482
#6 0x00007ffff7bcac16 in splt_tp_get_original_tags_and_append (
error=0x7fffffffdbf0, state=0x60ddb0) at tags_parser.c:545
#7 splt_tp_process_original_tags_variable (tpu=tpu@entry=0x61f800,
state=state@entry=0x60ddb0, error=error@entry=0x7fffffffdbf0,
set_original_tags=1) at tags_parser.c:514
#8 0x00007ffff7bcb4d1 in splt_tp_process_tag_variable (error=0x7fffffffdbf0,
state=0x60ddb0, tpu=0x61f800, end_paranthesis=0x7ffff7bcf14c "]",
tag_variable_start=0x7ffff7bcf146 "o,@N=1]") at tags_parser.c:363
#9 splt_tp_process_tags (error=0x7fffffffdbf0, state=0x60ddb0, tpu=0x61f800,
tags=0x7ffff7bcf143 "%[@o,@N=1]") at tags_parser.c:293
#10 splt_tp_put_tags_from_string (state=state@entry=0x60ddb0,
tags=tags@entry=0x7ffff7bcf143 "%[@o,@N=1]",
error=error@entry=0x7fffffffdbf0) at tags_parser.c:192
---Type <return> to continue, or q <return> to quit---
#11 0x00007ffff7bbb4f3 in mp3splt_split (state=state@entry=0x60ddb0)
at mp3splt.c:1232
#12 0x0000000000403320 in main (argc=<optimized out>,
orig_argv=<optimized out>) at mp3splt.c:872
(gdb)
--------------------
int vorbis_block_clear(vorbis_block *vb){
int i;
vorbis_block_internal *vbi=vb->internal;
_vorbis_block_ripcord(vb);
if(vb->localstore)_ogg_free(vb->localstore); <========
if(vbi){
for(i=0;i<PACKETBLOBS;i++){
oggpack_writeclear(vbi->packetblob[i]);
if(i!=PACKETBLOBS/2)_ogg_free(vbi->packetblob[i]);
}
_ogg_free(vbi);
}
memset(vb,0,sizeof(*vb));
return(0);
}
```https://gitlab.xiph.org/xiph/OggIndex/-/issues/1OggIndex needs opus support2017-09-25T22:33:09ZGitlab BotOggIndex needs opus supportRight now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
https://git.xiph.org/?p=OggIndex.git;a=treeRight now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
https://git.xiph.org/?p=OggIndex.git;a=treehttps://gitlab.xiph.org/xiph/theora/-/issues/2305a div zero vul in function fetch_and_process_audio() in libtheora 1.1.12017-09-14T09:24:23ZJiangxina div zero vul in function fetch_and_process_audio() in libtheora 1.1.1```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http:...```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from encoder_example...done.
(gdb) run ../fuzz/out/Master2/crashes/id:000000,sig:08,src:000000,op:flip1,pos:22 xxx.y4m
Compressing.... pgl쭌躲£¿K+y*ªFၑﲘ።ڗܙ䆾V䔍ᤆ"h1^E³¯¹3⛟䪩Rp¨푳meɆ
/
Program received signal SIGFPE, Arithmetic exception.
fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda10, vo=vo@entry=0x7fffffffde10, vd=vd@entry=0x7fffffffdb20, vb=vb@entry=0x7fffffffdbb0, audioflag=audioflag@entry=0) at encoder_example.c:947
947 int toread=4096/2/audio_ch;
(gdb) bt
#0 fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda10, vo=vo@entry=0x7fffffffde10, vd=vd@entry=0x7fffffffdb20, vb=vb@entry=0x7fffffffdbb0, audioflag=audioflag@entry=0) at encoder_example.c:947
#1 0x0000000000405a9b in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1754
(gdb) p audio_ch
$1 = 0
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2329(CVE-2017-14633)an out-of-bound array read vul in function mapping0_forward()...2017-12-11T08:15:06ZJiangxin(CVE-2017-14633)an out-of-bound array read vul in function mapping0_forward() in libvorbis 1.3.5```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 ...```
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples
╰$ gdb encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from encoder_example...done.
(gdb) run ../fuzz/crash-oob-read xxx.y4m
Program received signal SIGSEGV, Segmentation fault.
0x00000000005754f9 in mapping0_forward (vb=<optimized out>) at mapping0.c:501
500 if(ci->floor_type[info->floorsubmap[submap]]!=1)return(-1);
(gdb) bt
#0 0x00000000005754f9 in mapping0_forward (vb=<optimized out>) at mapping0.c:500
#1 0x00000000004d3512 in vorbis_analysis (vb=vb@entry=0x7fffffffdbe0, op=op@entry=0x0) at analysis.c:47
#2 0x0000000000410926 in fetch_and_process_audio (audio=0x83b010, audiopage=audiopage@entry=0x7fffffffda40, vo=vo@entry=0x7fffffffde40, vd=vd@entry=0x7fffffffdb50, vb=vb@entry=0x7fffffffdbe0, audioflag=audioflag@entry=0) at encoder_example.c:996
#3 0x0000000000405a9b in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1754
(gdb) i r
rax 0x84b420 8696864
rbx 0x1d3c1a0 30654880
rcx 0x100 256
rdx 0x1e332a0 31666848
rsi 0x1e32e70 31665776
rdi 0x85f000 8777728
rbp 0x7fffffffc850 0x7fffffffc850
rsp 0x7fffffff9ee0 0x7fffffff9ee0
r8 0x1a9b500 27899136
r9 0x8494f0 8688880
r10 0x3e9b02c6 1050346182
r11 0xfe 254
r12 0x1a9b900 27900160
r13 0x84e0e4 8708324
r14 0x84cc00 8702976
r15 0x1b93728 28915496
rip 0x5754f9 0x5754f9 <mapping0_forward+5737>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) x/i $pc
=> 0x5754f9 <mapping0_forward+5737>: cmpl $0x1,0x528(%r9,%r10,4)
(gdb) x/128xb $r9+$r10*4+0x528
0xfaf0a530: Cannot access memory at address 0xfaf0a530
```https://gitlab.xiph.org/xiph/vorbis/-/issues/2328(CVE-2017-14632)call oggpack_writeclear() with uninitialized stack var opb in...2018-05-09T21:59:56ZJiangxin(CVE-2017-14632)call oggpack_writeclear() with uninitialized stack var opb in function vorbis_analysis_headerout() when vi->channels<=0 in libvorbis 1.3.5```
int vorbis_analysis_headerout(vorbis_dsp_state *v,
577 vorbis_comment *vc,
578 ogg_packet *op,
579 ogg_packet *op_comm,
580 ...```
int vorbis_analysis_headerout(vorbis_dsp_state *v,
577 vorbis_comment *vc,
578 ogg_packet *op,
579 ogg_packet *op_comm,
580 ogg_packet *op_code){
581 int ret=OV_EIMPL;
582 vorbis_info *vi=v->vi;
583 oggpack_buffer opb;
584 private_state *b=v->backend_state;
585
586 if(!b||vi->channels<=0){
587 ret=OV_EFAULT;
588 goto err_out;
589 }
...
639 err_out:
640 memset(op,0,sizeof(*op));
641 memset(op_comm,0,sizeof(*op_comm));
642 memset(op_code,0,sizeof(*op_code));
643
644 if(b){
645 oggpack_writeclear(&opb);
646 if(b->header)_ogg_free(b->header);
647 if(b->header1)_ogg_free(b->header1);
648 if(b->header2)_ogg_free(b->header2);
649 b->header=NULL;
650 b->header1=NULL;
651 b->header2=NULL;
652 }
as shown above, if vi->channels<=0 and b!=NULL then func goes to err_out with opb uninitialized, but before calling oggpack_writeclear, it only check if(b),so it will ultimately free a uninitialized memory in oggpack_writeclear:
250 void oggpack_writeclear(oggpack_buffer *b){
251 if(b->buffer)_ogg_free(b->buffer);
252 memset(b,0,sizeof(*b));
253 }
This vul may lead to a DOS or Remote Code Execution in products using libvorbis 1.3.5(latest version).
By the way, I found 8 years ago this function has been found a similar vul :https://bugzilla.mozilla.org/show_bug.cgi?id=550184
while cause of no check of if b=NULL before calling oggpack_writeclear. This time , it is because of incorrect check while no considering if vi->channels<=0.
To reproduce this vul, compile libtheora 1.1.1 libvorbis 1.3.5 libogg 1.3.2 ,then run as below:
╭─root@linux-jiangxin in /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/fuzz
╰$ gdb ../examples/encoder_example
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../examples/encoder_example...done.
(gdb) run out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 xxx.y4m
Starting program: /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 xxx.y4m
File out/Master/crashes/id:000000,sig:06,src:000000,op:flip1,pos:22 is 16 bit 0 channel 44100 Hz RIFF WAV audio.
File xxx.y4m is 176x144 29.97 fps mono video.
*** glibc detected *** /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example: munmap_chunk(): invalid pointer: 0x00007fffffffdb30 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x76628)[0x7ffff7864628]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x4a4505]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x504090]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x40535d]
/lib64/libc.so.6(__libc_start_main+0xe6)[0x7ffff780cc36]
/home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example[0x40a039]
======= Memory map: ========
00400000-0063a000 r-xp 00000000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
00839000-0083a000 r--p 00239000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
0083a000-0083b000 rw-p 0023a000 08:08 6452963 /home/jiangxin/experiment/fuzz/AFL/target/libtheora-1.1.1/examples/encoder_example
0083b000-008e6000 rw-p 00000000 00:00 0 [heap]
7ffff75d7000-7ffff75ed000 r-xp 00000000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff75ed000-7ffff77ec000 ---p 00016000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ec000-7ffff77ed000 r--p 00015000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ed000-7ffff77ee000 rw-p 00016000 08:07 155653 /usr/local/lib64/libgcc_s.so.1
7ffff77ee000-7ffff795c000 r-xp 00000000 08:07 131081 /lib64/libc-2.11.3.so
7ffff795c000-7ffff7b5b000 ---p 0016e000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b5b000-7ffff7b5f000 r--p 0016d000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b5f000-7ffff7b60000 rw-p 00171000 08:07 131081 /lib64/libc-2.11.3.so
7ffff7b60000-7ffff7b65000 rw-p 00000000 00:00 0
7ffff7b65000-7ffff7bc0000 r-xp 00000000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7bc0000-7ffff7dbf000 ---p 0005b000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dbf000-7ffff7dc0000 r--p 0005a000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dc0000-7ffff7dde000 rw-p 0005b000 08:07 131089 /lib64/libm-2.11.3.so
7ffff7dde000-7ffff7dfd000 r-xp 00000000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7f24000-7ffff7fc1000 rw-p 00000000 00:00 0
7ffff7fc8000-7ffff7ff8000 rw-p 00000000 00:00 0
7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0 [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 0001e000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7ffd000-7ffff7ffe000 rw-p 0001f000 08:07 131074 /lib64/ld-2.11.3.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
OggSa8W!۰ہ*theora
°u0迵@
Program received signal SIGABRT, Aborted.
0x00007ffff7820b55 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7820b55 in raise () from /lib64/libc.so.6
#1 0x00007ffff7822131 in abort () from /lib64/libc.so.6
#2 0x00007ffff785ee0f in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff7864628 in malloc_printerr () from /lib64/libc.so.6
#4 0x00000000004a4505 in oggpack_writeclear (b=b@entry=0x7fffffffda10) at bitwise.c:251
#5 0x0000000000504090 in vorbis_analysis_headerout (v=v@entry=0x7fffffffdcb0, vc=vc@entry=0x7fffffffdb50, op=op@entry=0x7fffffffdba0, op_comm=op_comm@entry=0x7fffffffdbd0, op_code=op_code@entry=0x7fffffffdc00) at info.c:645
#6 0x000000000040535d in main (argc=<optimized out>, argv=<optimized out>) at encoder_example.c:1688
(gdb) detach
files attached:
weird, I can not attach file here, so if you need please contact me for the the crash sample.
```
This issue has been assigned a CVE number :CVE-2017-14632