Opusfile issueshttps://gitlab.xiph.org/xiph/opusfile/-/issues2023-05-02T13:41:35Zhttps://gitlab.xiph.org/xiph/opusfile/-/issues/23330.12: broken include/opusfile.h or missing include/opus_multistream.h2023-05-02T13:41:35ZTomasz Kłoczko0.12: broken include/opusfile.h or missing include/opus_multistream.hLooks like something is wrong with opusfile header files. Build of the SDL2_mixer failed with:
```
In file included from src/codecs/music_opus.c:34:
/usr/include/opus/opusfile.h:110:11: fatal error: opus_multistream.h: No such file or di...Looks like something is wrong with opusfile header files. Build of the SDL2_mixer failed with:
```
In file included from src/codecs/music_opus.c:34:
/usr/include/opus/opusfile.h:110:11: fatal error: opus_multistream.h: No such file or directory
110 | # include <opus_multistream.h>
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
```
however wehn I've started looking on opusfile repo looks like there is no such file.
```
[tkloczko@pers-jacek opusfile]$ grep -r opus_multistream.h
include/opusfile.h:# include <opus_multistream.h>
[tkloczko@pers-jacek opusfile]$ find . -name opus_multistream.h
[tkloczko@pers-jacek opusfile]$
```https://gitlab.xiph.org/xiph/opusfile/-/issues/2332Unable to access opusfile 0.12 sections documentation2021-10-25T13:38:43ZDario-GasquezUnable to access opusfile 0.12 sections documentationHi,
I am able to access opusfile main documentation page here:<br>
https://opus-codec.org/docs/opusfile_api-0.12/index.html<br>
(as well as its PDF version)<br>
But the different sections look empty, tried with:<br>
Opening and Closing...Hi,
I am able to access opusfile main documentation page here:<br>
https://opus-codec.org/docs/opusfile_api-0.12/index.html<br>
(as well as its PDF version)<br>
But the different sections look empty, tried with:<br>
Opening and Closing: https://opus-codec.org/docs/opusfile_api-0.12/group__stream__open__close.html<br>
(screenshot attached)<br>
Decoding: https://opus-codec.org/docs/opusfile_api-0.12/group__stream__decoding.html<br>
The last version available seems to be 0.7, both its HTML and PDF formats:<br>
https://opus-codec.org/docs/opusfile_api-0.7/group__stream__decoding.html<br>
https://opus-codec.org/docs/opusfile_api-0.7.pdf<br>
<br>
<br>
Thanks in advance<br>
<br>
![opusfile-0.12-empty-doc-section](/uploads/bbc806153651c8f267c2ee7abd51c467/opusfile-0.12-empty-doc-section.png)https://gitlab.xiph.org/xiph/opusfile/-/issues/2327Build fails with LibreSSL: ./.libs/libopusurl.so: undefined reference to `BIO...2020-06-24T22:38:20ZStefan StroginBuild fails with LibreSSL: ./.libs/libopusurl.so: undefined reference to `BIO_meth_set_puts'LibreSSL 2.6.5, Gentoo Linux.
```
src/http.c: In function ‘op_bio_retry_new’:
src/http.c:1540:3: warning: implicit declaration of function ‘BIO_set_init’; did you mean ‘BIO_sock_init’? [-Wimplicit-function-declaration]
BIO_set_init(_...LibreSSL 2.6.5, Gentoo Linux.
```
src/http.c: In function ‘op_bio_retry_new’:
src/http.c:1540:3: warning: implicit declaration of function ‘BIO_set_init’; did you mean ‘BIO_sock_init’? [-Wimplicit-function-declaration]
BIO_set_init(_b,1);
^~~~~~~~~~~~
BIO_sock_init
src/http.c:1544:3: warning: implicit declaration of function ‘BIO_set_data’; did you mean ‘BIO_set_ex_data’? [-Wimplicit-function-declaration]
BIO_set_data(_b,NULL);
^~~~~~~~~~~~
BIO_set_ex_data
```
and so on.
Full [build.log](/uploads/e3c105fc852d754257bce86f654210a4/build.log)
See also: https://bugs.gentoo.org/588768https://gitlab.xiph.org/xiph/opusfile/-/issues/2325Double Free in opusfile2020-06-24T22:38:19ZGitlab BotDouble Free in opusfileAs part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the saniti...As part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the sanitizers that it offers (this issue was discovered using [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer).
To reproduce you will need to build your project using that sanitizer, and execute the attached stub code on the reproducer input that we have also provided. This stub code could also serve as a useful template for
fuzzing in your project with l[libFuzzer](http://libfuzzer.info) and/or [AFL](http://lcamtuf.coredump.cx/afl/), which may help you uncover additional issues. Some documentation on how to get started with libFuzzer is here:
- [Getting Started Documentation](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [LibFuzzer Tutorial](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [OSS-Fuzz target example](https://github.com/google/oss-fuzz/blob/a143b9b39a51412d133f846688194d68fe4197ba/projects/libchewing/chewing_default_fuzzer.c)
The following options / environment variables may be necessary for
accurate reproduction of the issue as well:
```
ASAN_OPTIONS="exitcode=1,handle_segv=1,detect_leaks=1,leak_check_at_exit=1,a
llocator_may_return_null=1,detect_odr_violation=0"
MSAN_OPTIONS=...
}}}
The sanitizer error that we encountered is here:
{{{
==779726==ERROR: LeakSanitizer: detected memory leaks
SUMMARY: AddressSanitizer: 78 byte(s) leaked in 4 allocation(s).
}}}
Other relevant info/repro instructions:
{{{
** Repro:
git clone https://git.xiph.org/opusfile.git
sudo apt-get install libogg-dev libopus-dev
CC="clang-3.8" CFLAGS="-O1 -g -fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound -fno-sanitize-recover=all -fno-omit-frame-pointer -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION=1" CXX="clang++-3.8" CXXFLAGS="-O1 -g -fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound -fno-sanitize-recover=all -fno-omit-frame-pointer -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION=1" LDFLAGS="-g -fsanitize=address,bool,float-cast-overflow,integer-divide-by-zero,return,returns-nonnull-attribute,shift-exponent,unreachable,vla-bound" ./configure && make
./examples/opusfile_example ./34286806_leak-c99edf095c8159361c13c868fbf7b257371a4007-min
** Analysis:
The issue is in src/info.c.
This call to opus_tags_parse_impl() fails, and opus_tags_clear() is called:
226 ret=opus_tags_parse_impl(&tags,_data,_len);
227 if(ret<0)opus_tags_clear(&tags);
It fails at this line:
192 _data+=4;
193 len-=4;
194 if(count>len)return OP_EBADHEADER;
because count = 0x43000026 and length = 0x26.
Then at this line:
99 for(ci=ncomments;ci-->0;)_ogg_free(_tags->user_comments[ci]);
It frees memory that I don't think was ever allocated:
_tags->user_comments[ci] => 0xbebebebebebebebe
```
We will gladly work with you so you can successfully confirm and reproduce
this issue. Do let us know if you have any feedback surrounding the
documentation.
Once you have reproduced the issue, we’d appreciate to learn your expected
timeline for an update to be released. With any fix, please attribute the
report to “Google Autofuzz project”.
We are also pleased to inform you that your project is also eligible for
inclusion to the OSS-Fuzz project, which can provide additional continuous
fuzzing, and encourage you to investigate [https://github.com/google/oss-
fuzz/blob/master/docs/new_project_guide.md integration options].
Don’t hesitate to let us know if you have any questions!
Google AutoFuzz Teamhttps://gitlab.xiph.org/xiph/opusfile/-/issues/2324opus_tags_parse_impl: Fix free of uninitialised data2020-06-24T22:38:19ZGitlab Botopus_tags_parse_impl: Fix free of uninitialised dataAs part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the saniti...As part of our [fuzzing](https://www.owasp.org/index.php/Fuzzing) efforts at Google, we have identified an issue in git HEAD of opusfile. To reproduce requires compiling the project with the LLVM compiler, taking advantage of the sanitizers that it offers (this issue was discovered using [AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer).
To reproduce you will need to build your project using that sanitizer, and execute the attached stub code on the reproducer input that we have also provided. This stub code could also serve as a useful template for fuzzing in your project with l[libFuzzer](http://libfuzzer.info) and/or [AFL](http://lcamtuf.coredump.cx/afl/), which may help you uncover additional issues. Some documentation on how to get started with libFuzzer is here:
- [Getting Started Documentation](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [LibFuzzer Tutorial](http://llvm.org/docs/LibFuzzer.html#getting-started)
- [OSS-Fuzz target example](https://github.com/google/oss-fuzz/blob/a143b9b39a51412d133f846688194d68fe4197ba/projects/libchewing/chewing_default_fuzzer.c)
The following options / environment variables may be necessary for accurate reproduction of the issue as well:
```
ASAN_OPTIONS="exitcode=1,handle_segv=1,detect_leaks=1,leak_check_at_exit=1,a llocator_may_return_null=1,detect_odr_violation=0"
MSAN_OPTIONS=...
```
The sanitizer error that we encountered is here:
```
==834381==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000000448ea4 bp 0x7fff554ee620 sp 0x7fff554ee5f0 T0)
==834381==The signal is caused by a READ memory access.
==834381==Hint: address points to the zero page.
```
Other relevant info/repro instructions:
```
The crash occurs during parsing of invalid user_comments tags.
I configured with:
CC=clang-3.6 CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer" ./configure --enable-static --disable-shared
And built with:
clang-3.6 -fno-omit-frame-pointer -g -fsanitize=address -Iinclude -I /usr/include/opus/ -L .libs -o poc poc.c -lopusfile -logg -lopus
I'm not familiar with opusfile, but I think the chain of events is:
1. opus_tags_parse() is called, calls opus_tags_parse_impl()
2. opus_tags_parse_impl() starts parsing, gets an okay preamble and comment count of 1
3. opus_tags_parse_impl() calls op_tags_ensure_capacity() to allocate _tags->user_comments
4. opus_tags_parse_impl() user_comments parsing loop encounters a comment with a nonsensical length, returns with error *without* initialising the comment.
5. opus_tags_parse() calls opus_tags_clear() which has this test:
if(_tags->user_comments!=NULL)ncomments++;
for(ci=ncomments;ci-->0;)_ogg_free(_tags->user_comments[ci]);
It assumes that if _tags->user_comments was allocated, then its contents are valid but this isn't the case because of #4.
Always initialising _tags->user_comments[ci] in opus_tags_parse_impl() should be sufficient fix this.
```
Suggested fix in libopusfile/src/info.c:
```
if(_tags!=NULL) _tags->user_comments[ci]=NULL;
```
We will gladly work with you so you can successfully confirm and reproduce this issue. Do let us know if you have any feedback surrounding the documentation.
Once you have reproduced the issue, we’d appreciate to learn your expected timeline for an update to be released. With any fix, please attribute the report to “Google Autofuzz project”.
We are also pleased to inform you that your project is also eligible for inclusion to the OSS-Fuzz project, which can provide additional continuous fuzzing, and encourage you to investigate [ integration options](https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md).
Don’t hesitate to let us know if you have any questions!
Google AutoFuzz Team
https://gitlab.xiph.org/xiph/opusfile/-/issues/2172opusfile-0.6 does not compile on MacOSX 10.5.8: AI_NUMERICSERV2018-07-04T14:02:14ZJan Staryopusfile-0.6 does not compile on MacOSX 10.5.8: AI_NUMERICSERVOn older systems such as MacOSX 10.5.8,
the AI_NUMERICSERV is not defined
and so src/http.c fails to compile:
The culprit is
```
#if !defined(_WIN32)
hints.ai_flags=AI_NUMERICSERV;
#endif
```
The simplest remedy seems to be to chec...On older systems such as MacOSX 10.5.8,
the AI_NUMERICSERV is not defined
and so src/http.c fails to compile:
The culprit is
```
#if !defined(_WIN32)
hints.ai_flags=AI_NUMERICSERV;
#endif
```
The simplest remedy seems to be to check for
```
#if defined(AI_NUMERICSERV)
```
instead.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opusfile/-/issues/2015can not decode the opus file2018-07-04T14:02:14Zgrueclancan not decode the opus fileJean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opusfile/-/issues/2014opusfile-0.5: avoid using obsolete ftime()2018-07-04T14:02:14ZThomas Klausneropusfile-0.5: avoid using obsolete ftime()NetBSD does not provide ftime(). This stops compilation of opusfile-0.5.
The linux man page for ftime() says "This function is obsolete. Don't use it.".
The attached patch converts src/http.c to use gettimeofday() instead.NetBSD does not provide ftime(). This stops compilation of opusfile-0.5.
The linux man page for ftime() says "This function is obsolete. Don't use it.".
The attached patch converts src/http.c to use gettimeofday() instead.Timothy B. TerriberryTimothy B. Terriberryhttps://gitlab.xiph.org/xiph/opusfile/-/issues/1960opusfile-0.2 does not build on osx2018-07-04T14:02:14ZCullen Jenningsopusfile-0.2 does not build on osx
Fails when doing the "configure" on osx, it tells you to
Alternatively, you may set the environment variables DEPS_CFLAGS
and DEPS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
if you don't...
Fails when doing the "configure" on osx, it tells you to
Alternatively, you may set the environment variables DEPS_CFLAGS
and DEPS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
if you don't have pkg-config. Yet when you set them, it still fails.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opusfile/-/issues/1927opusfile segfaults in op_mem_read2018-07-04T14:02:14Zlaxyopusfile segfaults in op_mem_read```
==16136== Thread 1:
==16136== Invalid write of size 1
==16136== at 0x4C26597: memcpy (in /opt/valgrind/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16136== by 0x4094AD: op_mem_read (stream.c:114)
==16136== by 0x4029B2: ...```
==16136== Thread 1:
==16136== Invalid write of size 1
==16136== at 0x4C26597: memcpy (in /opt/valgrind/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16136== by 0x4094AD: op_mem_read (stream.c:114)
==16136== by 0x4029B2: op_get_data (opusfile.c:146)
==16136== by 0x402B7A: op_get_next_page (opusfile.c:203)
==16136== by 0x403626: op_fetch_headers (opusfile.c:569)
==16136== by 0x40593A: op_open1 (opusfile.c:1490)
==16136== by 0x405B44: op_test_callbacks (opusfile.c:1546)
==16136== by 0x405BD2: op_open_callbacks (opusfile.c:1560)
==16136== by 0x405C91: op_open_close_on_failure (opusfile.c:1580)
==16136== by 0x405D2A: op_open_memory (opusfile.c:1593)
==16136== by 0x4026B1: mainloop() (mainloop.cpp:9)
==16136== by 0x402649: main (main.cpp:99)
==16136== Address 0x60c5803 is not stack'd, malloc'd or (recently) free'd
==16136==
==16136== Invalid write of size 8
==16136== at 0x4C265B1: memcpy (in /opt/valgrind/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16136== by 0x4094AD: op_mem_read (stream.c:114)
==16136== by 0x4029B2: op_get_data (opusfile.c:146)
==16136== by 0x402B7A: op_get_next_page (opusfile.c:203)
==16136== by 0x403626: op_fetch_headers (opusfile.c:569)
==16136== by 0x40593A: op_open1 (opusfile.c:1490)
==16136== by 0x405B44: op_test_callbacks (opusfile.c:1546)
==16136== by 0x405BD2: op_open_callbacks (opusfile.c:1560)
==16136== by 0x405C91: op_open_close_on_failure (opusfile.c:1580)
==16136== by 0x405D2A: op_open_memory (opusfile.c:1593)
==16136== by 0x4026B1: mainloop() (mainloop.cpp:9)
==16136== by 0x402649: main (main.cpp:99)
==16136== Address 0x60c57f8 is not stack'd, malloc'd or (recently) free'd
```
Using opus 1.0.2, opusfile 0.2, and doing this:
```
// load file to RAM. The length parameter is confirmed correct.
OggOpusFile* op = op_open_memory(ptr, len, NULL);
```
I get a segfault. It seems to happen no matter what opus file I use, but attaching one file of silence that makes it happen here.Jean-Marc ValinJean-Marc Valin