Discussion:
Bug#883118: gmediarender crashes when gets an upnp search
(too old to reply)
csaba mate
2017-11-29 21:50:01 UTC
Permalink
Package: gmediarender
Version: 0.0.7~git20160329+repack-1
Severity: normal

Dear Maintainer,

as usually, last weekend i upgraded my sid boxes.
these run gmediarender. now i restarted two of them,
then noticed that gmediarender crashes just after the
first incoming upnp search. i dist-upgraded again,
but the issue still exists.
i see this if i start from the terminal:
***@acer:~$ gmediarender
gmediarender 0.0.7-git started [ gmediarender 0.0.7-git (libupnp-1.6.19+git20160116; glib-2.49.6; gstreamer-1.8.3) ].
Logging switched off. Enable with --logfile=<filename> (e.g. --logfile=/dev/stdout for console)
Segmentation fault
***@acer:~$
i see this in the dmesg:
[ 9788.977982] gmediarender[6368]: segfault at 0 ip 00007f4cbc7cd375 sp 00007f4c2893c1b0 error 4 in libupnp.so.6.4.0[7f4cbc7b7000+36000]
i see this packet as a trigger, but probaby others will do:
User Datagram Protocol, Src Port: 40871, Dst Port: 1900
Source Port: 40871
Destination Port: 1900
Length: 157
Checksum: 0xafb8 [correct]
[Calculated Checksum: 0xafb8]
[Checksum Status: Good]
[Stream index: 50]
Simple Service Discovery Protocol
M-SEARCH * HTTP/1.1\r\n
[Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
[M-SEARCH * HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: M-SEARCH
Request URI: *
Request Version: HTTP/1.1
HOST: 239.255.255.250:1900\r\n
MAN: "ssdp:discover"\r\n
MX: 3\r\n
ST: upnp:rootdevice\r\n
USER-AGENT: Android/25 UPnP/1.1 UPnPTool/1.4.8\r\n
\r\n
[Full request URI: http://239.255.255.250:1900*]
[HTTP request 1/1]
to trigger, i used android's upnptool.


-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gmediarender depends on:
ii libc6 2.25-2
ii libglib2.0-0 2.54.2-1
ii libgstreamer1.0-0 1.12.3-1
ii libupnp6 1:1.6.24-1
ii lsb-base 9.20170808

Versions of packages gmediarender recommends:
ii gstreamer1.0-plugins-good 1.12.3-1

Versions of packages gmediarender suggests:
pn gstreamer-plugins-ugly <none>
ii gstreamer1.0-plugins-bad 1.12.3-2

-- no debconf information
Tobias Frost
2017-12-05 21:00:01 UTC
Permalink
Control: tags -1 confirmed
Control: severity -1 serious

Hi,

thanks for the notice. I saw the segfault also when I was debugging
#881456 but I could not spend enough time on it...
It seesm that the crash occurs deep inside libupnpr6...

Will try to spend some time debugging this on the weekend.

--
tobi
Tobias Frost
2017-12-10 17:00:02 UTC
Permalink
Control: reassign -1 libupnp 1:1.6.24
Control: retitle -1 libupnp: SEGV in upnp/src/genlib/net/http/httpreadwrite.c:1662
Control: affects -1 gmediarender

Hallo Uwe,

I'm reassigning this bug as I'm suspecting it in the recent release of libupnp,
after I had debugged it a bit.

The bug does not trigger in 1.6.22.

How to reproduce:

Install gmediarender and (as a DLNA/uPnP control point) gupnp-tools.

run gmediarender , eg. gmediarender --logfile=/dev/stdout and then the DLNA
controlpoint, e.g gupnp-av-cp

As soon as the the cp queries for the DLNA server, gmediarender crashes.

Debugging into it it segfaults in upnp/src/genlib/net/http/httpreadwrite.c:1662
deferencing a NULL pointer (extras being NULL); it is called from
upnp/src/genlib/net/http/webserver.c:1316; the relvant paremter is
"extra_headers", passed for the "E" command (its NULL)

Looking at the diff from 1.6.22 it looks like that this has been touched:
- before, extra_headers was a string and if NULL it would have been set to an
empty string ("" == '\0')
- now it is a struct which will be only allocated conditionally (line 1188 in
webserver.c). Otherwise it is NULL.
- before, it used command "s" not "E"...

Adding this patch:

--- a/upnp/src/genlib/net/http/webserver.c
+++ b/upnp/src/genlib/net/http/webserver.c
@@ -1296,6 +1296,12 @@
goto error_handler;
}

+ if (!extra_headers) {
+ extra_headers = (struct Extra_Headers*) malloc(sizeof(struct Extra_Headers));
+ if (!extra_headers) goto error_handler;
+ extra_headers->name = NULL;
+ }
+
/* Check if chunked encoding should be used. */
if (using_virtual_dir && finfo.file_length == UPNP_USING_CHUNKED) {
/* Chunked encoding is only supported by HTTP 1.1 clients */

seems to fix the crash, but as soon after the assertion on httpreadwrite:1862
will trigger. It looks like that in line 1672 a "else" is missing to correctly
chain up the commands after the new "E" command:

--- a/upnp/src/genlib/net/http/httpreadwrite.c
+++ b/upnp/src/genlib/net/http/httpreadwrite.c
@@ -1668,8 +1668,7 @@
}
extras++;
}
- }
- if (c == 's') {
+ } else if (c == 's') {
/* C string */
s = (char *)va_arg(argp, char *);
assert(s);


When applying the patch (attached), gmediarender stops crashing.
However, I cannot say if my changes are sane at all, thus not tagging
"patch". (and also I neglected return code checking of malloc)

Let me know if you need some details!

Cheers,
tobi
Tobias Frost
2017-12-11 09:40:01 UTC
Permalink
Sigh...
It segfaults again...
Try to recompile libupnp with the patch provided there.
If it crashes with current libupnp -- this is a good sign as then it had received the upnp query. If not, I guess it is a network/firewall/like thing
I do not see what changed...
I guess it is something on my machine if nobody else can reproduce. I
guess
you may want to close the bug.
Thanks :)
Marcos
hi,
i cannot confirm this: i run a lot of gmediarenderers, i've just
dist-upgraded them,
and all showed up. i've tried one of them and plays nicely.
for discovery, i used android's upnptool, but also given try to
the mentioned bubbleupnp, both works. for playback, i used android's
tubio.
interestingly, pulseaudio-dlna discovers (attached pic) but have no
sound.
i'll investigate it and update this bug or file a new one if needed.
(mine is a routed network, i route multicast for the discovery),
but i don't think so that it matters at all.
regards,
cs
Hi Tobias.
I have installed the one from unstable. It does not segfault.
Still not showing in renderers.
They are certainly in the same network, and I can see and use in
bublepnp my minidlna server, which is in the same machine, as well
as my
other renderer which is a chromecast, still in the same network.
Do you have anything else that I could try/test?
Much appreciated :)
Control: tags -1 confirmed
Control: severity -1 serious
Hi,
thanks for the notice. I saw the segfault also when I was
debugging
#881456 but I could not spend enough time on it...
It seesm that the crash occurs deep inside libupnpr6...
Will try to spend some time debugging this on the weekend.
--
tobi
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Loading...