Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-04-12T11:02:45Zhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2316Cannot connect to server in nonblocking mode ("Please retry current operation.")2022-04-12T11:02:45ZTomasz LemiechCannot connect to server in nonblocking mode ("Please retry current operation.")After reenabling nonblocking sockets by applying the fix (workaround?) described in https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 the client is unable to connect to the server at all. HTTP request is sent, but the client clos...After reenabling nonblocking sockets by applying the fix (workaround?) described in https://gitlab.xiph.org/xiph/icecast-libshout/issues/2315 the client is unable to connect to the server at all. HTTP request is sent, but the client closes the connection before the reply arrives.
```
$ ./nonblocking
Error connecting: Please retry current operation.
```
strace shows the following:
```
$ strace -e connect,fcntl,fcntl64,select ./nonblocking
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(5, [4], [4], [4], {tv_sec=0, tv_usec=1000}) = 1 (out [4], left {tv_sec=0, tv_usec=999})
select(5, NULL, [4], NULL, {tv_sec=0, tv_usec=0}) = 1 (out [4], left {tv_sec=0, tv_usec=0})
select(5, [4], NULL, [4], {tv_sec=0, tv_usec=1000}) = 0 (Timeout)
Error connecting: Please retry current operation.
+++ exited with 0 +++
```
The third `select` call times out. Backtrace at this `select` call:
```
#0 __GI___select (nfds=5, readfds=readfds@entry=0x7fffffffc6c0, writefds=writefds@entry=0x0,
exceptfds=exceptfds@entry=0x7fffffffc7c0, timeout=timeout@entry=0x7fffffffc6b0) at ../sysdeps/unix/sysv/linux/select.c:39
#1 0x00007ffff7f78f3e in shout_connection_iter__wait_for_io (con=con@entry=0x55555555aa10, for_write=for_write@entry=0,
timeout=timeout@entry=0, shout=0x55555555a490, for_read=1) at connection.c:144
#2 0x00007ffff7f7961c in shout_connection_iter__message (shout=0x55555555a490, con=0x55555555aa10) at connection.c:374
#3 shout_connection_iter (shout=<optimized out>, con=<optimized out>) at connection.c:478
#4 shout_connection_iter (con=con@entry=0x55555555aa10, shout=shout@entry=0x55555555a490) at connection.c:442
#5 0x00007ffff7f77571 in try_connect (self=self@entry=0x55555555a490) at shout.c:1333
#6 0x00007ffff7f77752 in shout_open (self=0x55555555a490) at shout.c:189
#7 0x000055555555529b in main () at nonblocking.c:66
```
As a result of this timeout, `shout_connection_iter__wait_for_io` returns `SHOUT_RS_TIMEOUT` to `shout_connection_iter__message`, which then gets propagated back to `shout_connection_iter`. Now due to the following condition in `__iter` macro:
```C
case SHOUT_RS_TIMEOUT: \
case SHOUT_RS_NOTNOW: \
if (con->nonblocking == SHOUT_BLOCKING_NONE) \
return SHOUTERR_RETRY; \
retry = 1; \
```
`SHOUTERR_RETRY` is returned from `shout_connection_iter` and propagated back via `try_connect` and `shout_open` to the caller, which is usually not prepared to handle this value (it expects `SHOUTERR_SUCCESS`, `SHOUTERR_CONNECTED` or `SHOUTERR_BUSY`).
A one-line fix to the above:
```C
if (con->nonblocking == SHOUT_BLOCKING_NONE) \
return SHOUTERR_BUSY; \
```
fixes the problem.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2315Network socket not set to nonblocking mode despite using nonblocking API2020-10-23T07:06:28ZTomasz LemiechNetwork socket not set to nonblocking mode despite using nonblocking APIhttps://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can b...https://gitlab.xiph.org/xiph/icecast-libshout/commit/0ac7ed9e84c3871d4427acc1ce59dca5e4af21ef introduced a bug which causes network sockets not to be set into nonblocking mode when requested with `shout_set_nonblocking(s, 1)`. This can be demonstrated simply by tracing an example `nonblocking` app.
Bad (current master HEAD):
```
$ strace -f -e fcntl,fcntl64,socket,connect ./nonblocking
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
```
Good (v2.4.3):
```
(...)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
fcntl(4, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now i n progress)
```
In the first case `fcntl` is never called and the socket stays in the default (blocking) mode.
This is due to the following condition in `shout_connection_connect`:
```C
if (con->nonblocking == SHOUT_BLOCKING_DEFAULT)
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
But as `con->nonblocking` is never initialized to this value, it's effectively `if(0)`.
Adding a simple:
```C
con->nonblocking = SHOUT_BLOCKING_DEFAULT;
```
to `shout_connection_new` fixes the problem. But this turns the above condition into `if(1)`, so is it really needed? It was not there before. What's the idea behind this?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2381Multimedia signing key expired for openSUSE OBS Multimedia2022-04-12T14:00:12ZTom ZetMultimedia signing key expired for openSUSE OBS MultimediaThe Multimedia signing key as written in here [wiki.xiph.org](https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop) expired 2020-01-30.The Multimedia signing key as written in here [wiki.xiph.org](https://wiki.xiph.org/index.php?title=Icecast_Server/Installing_latest_version_(official_Xiph_repositories)&mobileaction=toggle_view_desktop) expired 2020-01-30.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2314Allow disabling installation of ckport database2020-02-11T08:40:50ZPetr PisarAllow disabling installation of ckport databaseI found out that libshout-2.4.3 installs libshout.ckport file although I have no use for it. An attached patch adds --disable-ckport configure option that allows users to disable the installation.
[libshout-2.4.3-Allow-disabling-ckport-...I found out that libshout-2.4.3 installs libshout.ckport file although I have no use for it. An attached patch adds --disable-ckport configure option that allows users to disable the installation.
[libshout-2.4.3-Allow-disabling-ckport-database-installation.patch](/uploads/18b0544b437ccba7c9dd352e25175354/libshout-2.4.3-Allow-disabling-ckport-database-installation.patch)https://gitlab.xiph.org/xiph/libxspf/-/issues/1212[crash] Interger underflow2020-12-01T17:25:12ZJinho Jung[crash] Interger underflowAffected component(s)
======================
- libxspf project(makeUriString function)
- uriparser project (uriToStringCharsRequiredA function)
Attack vector(s)
================
Adversary sends crafted movie playlist file and victim o...Affected component(s)
======================
- libxspf project(makeUriString function)
- uriparser project (uriToStringCharsRequiredA function)
Attack vector(s)
================
Adversary sends crafted movie playlist file and victim opens it with media player which is using libxspf library (such as VLC player).
Suggested description of the vulnerability for use in the CVE
===============================================================
makeUriString() function from Xspf class trusts the return values (i.e., int* charsRequired) from uriparser library; thus assumes positive value.
However, "uriparser" library's uriToStringCharsRequired() functions returns negative value on crafted URI string such as "http://example.co@" (actually the function should return NULL).
Due to this integer underflow, the code meets crash with heap alloction failure.
* libxspf
```c
XML_Char * makeUriString(UriUri const & uri) {
XML_Char * uriString;
int charsRequired;
if (uriToStringCharsRequired(&uri, &charsRequired) != URI_SUCCESS) {
// the uriparse should have return NULL!
return NULL;
}
charsRequired++;
// negative value are inserted to charsRequired (e.g., 0xffffffffff9e5331)
// allocator error here!
uriString = new XML_Char[charsRequired];
if (uriToString(uriString, &uri, charsRequired, NULL) != URI_SUCCESS) {
delete [] uriString;
return NULL;
}
return uriString;
}
```
Discoverer
===========
Jinho Jung (jinho.jung@gatech.edu, Georgia Institute of Technology)
Reference
=========
N/A
Additional Information
======================
1. PoC:
https://ffs.gtisc.gatech.edu/download/ca3502e783138c47/#WQ_4uRrb_CSkyHvA5fpJMg
2. How to reproduce
we use example application from libxspf
1) find read.cpp file and modify the file name to PoC's
2) compile and run the read program
3. We also report this problem to uriparser project teamhttps://gitlab.xiph.org/xiph/ogg/-/issues/2299Invalid shift in oggpack_read()2020-01-29T15:17:19ZMichael NiedermayerInvalid shift in oggpack_read()ossfuzz of ffmpeg - libvorbis (which uses libogg) possibly found a bug in libogg
```
bitwise.c:396:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x7f3378 in oggpack_read /src/ogg/src/bitwise...ossfuzz of ffmpeg - libvorbis (which uses libogg) possibly found a bug in libogg
```
bitwise.c:396:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x7f3378 in oggpack_read /src/ogg/src/bitwise.c:396:23
#1 0x7cb1eb in _vorbis_unpack_info /src/vorbis/lib/info.c:212:15
#2 0x7cb0f5 in vorbis_synthesis_headerin /src/vorbis/lib/info.c:409:16
#3 0x4c2d82 in oggvorbis_decode_init /src/ffmpeg/libavcodec/libvorbisdec.c:108:12
```
The code is possibly in need of a cast to unsigned but i have not looked deeply into it.
The full report and 2 testcases are at the link below (this is possible not publically accessible but i can give access to this to anyone from xiph or libogg who wants to look into it). The testcase would require ffmpeg+ossfuzz+libvorbis+libogg in a bloated docker image though sadly, so iam not sure how useful that testcase would be. For me it does not reproduce outside docker.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18710https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2313ezstream hangs with libshout2019-11-18T08:44:49Zzygmundezstream hangs with libshoutHi,
Some time ago I was reported ezstream hangs with version of libshout 2.4.3 but problem still exists even with master branch, after few houres stream stops and I need to kill -9 ezstream.
When I downgraded to 2.4.1 everything is perf...Hi,
Some time ago I was reported ezstream hangs with version of libshout 2.4.3 but problem still exists even with master branch, after few houres stream stops and I need to kill -9 ezstream.
When I downgraded to 2.4.1 everything is perfect.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2380Invalid JSON structure when title is empty2020-10-11T11:37:16ZEdwin HermannInvalid JSON structure when title is emptyBelow is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
...Below is a snippet of the JSON structure returned from /status-json.xsl when the song title is empty:
```
"stream_start":"Mon, 28 Oct 2019 10:49:00 +1300",
"stream_start_iso8601":"2019-10-28T10:49:00+1300",
"title": - ,
"dummy":null
}
```
The problem item here is "title". The resulting JSON string does not parse correctly because of the hyphen. To fix the bug, the hyphen should be enclosed in double-quotes.
The server whence this came is not mine so I am not able to determine why it is that the Icecast server is returning an unquoted hyphen. The server concerned has been that way for several days; the URL is http://219.89.83.33:8000/status-json.xslhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2312Use-after-free bug after reopening connection2020-10-21T08:50:27ZAlexander MilosUse-after-free bug after reopening connectionHello,
There have recently been some issues when using libshout in combination with MPD (the Music Player Daemon) which, after some investigation in collaboration with the author of MPD, have apparently been tracked to a bug in libshout...Hello,
There have recently been some issues when using libshout in combination with MPD (the Music Player Daemon) which, after some investigation in collaboration with the author of MPD, have apparently been tracked to a bug in libshout. MPD's author reported the issue but did so on your GitHub mirror, so in case you may have missed it I saw fit to report it here as well.
The gist of that bug report is as follows:
"Since libshout 2.4.2, the library crashes due to a use-after-free and double-free bug if an application reopens the connection using shout_open() after a previous connection with the same shout_t had been closed by shout_close().
See [MusicPlayerDaemon/MPD#622](https://github.com/MusicPlayerDaemon/MPD/issues/622) for details and valgrind logs.
The crash bug was introduced by commit 3110fe32"
The original bug report is here: [xiph/Icecast-libshout#17](https://github.com/xiph/Icecast-libshout/issues/17)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2311Add support for JWT tokens2023-03-18T10:25:44ZThiago SantosAdd support for JWT tokensAdds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Adds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/liboggz/-/issues/7Ten off by one errors?2019-08-13T16:55:34ZRalph GilesTen off by one errors?Moved from [ogg #2197](https://gitlab.xiph.org/xiph/ogg/issues/2197) reported by @dcb314.
[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowi...Moved from [ogg #2197](https://gitlab.xiph.org/xiph/ogg/issues/2197) reported by @dcb314.
[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it. [timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it. [timespec.c:131]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it. [timespec.c:135]: timespec.c:139 timespec.c:143 timespec.c:147 timespec.c:151 timespec.c:155https://gitlab.xiph.org/xiph/icecast-website/-/issues/20513rd party apps page - broken links2020-06-14T10:41:49ZYahav3rd party apps page - broken linksHey
There are two broken links at the 3rd party apps page:
KRADradio and FreeJ
I wasn't able to create a PR.
CheersHey
There are two broken links at the 3rd party apps page:
KRADradio and FreeJ
I wasn't able to create a PR.
Cheershttps://gitlab.xiph.org/xiph/icecast-common/-/issues/7Consider using LGPL for tests2019-07-10T06:29:46ZUnit 193Consider using LGPL for testsHowdy,
While packaging libigloo I noticed some new files (modified only by ph3-der-loewe) were licensed under the GPL-2 license, whereas the rest of the project were licensed under LGPL-2+. Upon querying in #icecast I was directed to f...Howdy,
While packaging libigloo I noticed some new files (modified only by ph3-der-loewe) were licensed under the GPL-2 license, whereas the rest of the project were licensed under LGPL-2+. Upon querying in #icecast I was directed to file an issue for tracking purposes.
For reference, the files I found were: src/tests/* src/buffer.c src/reportxml.c
Thanks!
~Unit 193First release as libiglooPhilipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2378There should be a stats value indicating how if a stream is in a stable state2022-02-27T20:06:54ZPhilipp SchafftThere should be a stats value indicating how if a stream is in a stable stateThere should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flap...There should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flapping stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-common/-/issues/6Socket layer should be converted to generic IO interface2019-07-10T06:00:36ZPhilipp SchafftSocket layer should be converted to generic IO interfaceThe current socket interface should be converted to the generic IO Interface as discussed in #5.The current socket interface should be converted to the generic IO Interface as discussed in #5.First release as libiglooPhilipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2377Icecast leaks memory in speex module when probing for codecs2019-06-28T08:06:23ZPhilipp SchafftIcecast leaks memory in speex module when probing for codecsIcecast currently leaks memory in codec probing within the speex module. This happens if the initial packet has less then 80 bytes.Icecast currently leaks memory in codec probing within the speex module. This happens if the initial packet has less then 80 bytes.Philipp SchafftPhilipp Schafft2019-06-28https://gitlab.xiph.org/xiph/icecast-common/-/issues/5There should be a generic IO layer2019-06-30T10:52:33ZPhilipp SchafftThere should be a generic IO layerThere should be a generic IO layer for files/sockets/.... It should also be used for the logging support.There should be a generic IO layer for files/sockets/.... It should also be used for the logging support.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2310libshout connects to the same port for ICY data and metadata connections2020-10-21T08:50:27ZPhilipp Schafftlibshout connects to the same port for ICY data and metadata connectionslibshout does the port increment for ICY data connections unconditionally and therefore also for metadata connections.
This is part of the multi-topic ticket #2308.libshout does the port increment for ICY data connections unconditionally and therefore also for metadata connections.
This is part of the multi-topic ticket #2308.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2309libshout's connection state maschine does not honor connection specific block...2020-10-21T08:50:27ZPhilipp Schafftlibshout's connection state maschine does not honor connection specific blocking settingCurrently libshout's connection state machine overrides it's own blocking setting in `shout_connection_connect()`:
```c
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
Using the setting from the parent objec...Currently libshout's connection state machine overrides it's own blocking setting in `shout_connection_connect()`:
```c
shout_connection_set_nonblocking(con, shout_get_nonblocking(shout));
```
Using the setting from the parent object should only be the default if no specific value was set.
See also: #2308Philipp SchafftPhilipp Schafft2019-06-28https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2308Source clients experience issues with 2.4.2 and latest release 2.4.32020-02-17T20:23:01ZThomas B. RückerSource clients experience issues with 2.4.2 and latest release 2.4.3Migrated from GitHub: https://github.com/xiph/Icecast-libshout/issues/14
Users report random "hangs" and being unable to connect. We need a better understanding of what goes wrong on a technical level.Migrated from GitHub: https://github.com/xiph/Icecast-libshout/issues/14
Users report random "hangs" and being unable to connect. We need a better understanding of what goes wrong on a technical level.Philipp SchafftPhilipp Schafft