subdirectory
Out-of-tree builds seem to be currently broken, because ixml and
threadutil files need an include path to include UpnpGlobal.h, and
configure tries to copy files into a directory which it does not create.
The patch fixes both issues.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit c124ae6507)
Tested through the public function UpnpResolveURL2().
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit a596abfbe3)
This reworks commit 0edaf3361d, which
broke resolving relative url, where the relative URL is shorter than the
absolute URL:
"http://127.0.0.1:6544/getDeviceDesc" + "CDS_Event"
Wrong: "http://127.0.0.1:6544/CDS_EventDesc"
Right: "http://127.0.0.1:6544/CDS_Event"
While reviewing that commit, improve code by:
1. Move the simple cases to the beginning of the function.
2. Keep track of the remaining target buffer size.
3. Fix URI concatenation with queries.
4. Fix URI concatenation with fragments.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit 0508fb0d6e)
commit 0edaf3361d replaced several
malloc()+strcat() sequences with strncat() using strlen() on the
*source* string.
This is still vulnerable to overwrite the *target* buffer.
While reviewing this commit change the code to directly use snprintf()
for concatenating strings and check the length of the target buffer.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit 848d66e69d)
commit 0edaf3361d replaced several
malloc()+strcpy() sequences with memset()+strncpy() using strlen().
This doesn't improve security and introduced a bug URI handling.
While reviewing this commit change the code to directly use strdup()
instead of re-implementing it multiple times, as shortens the code and
thus improves readability.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit 04fb684323)
Commit b116d10f did the following change:
Use switch, int and sa_family_t with AF_INET in uri.c.
This breaks when getaddrinfo() only returns a single record, as in that
case the "break" only exits the switch statement and the loop-step
"res=res->ai_next" is still executed. After that "res == NULL" is
wrongly interpreted as not having found an AF_INET or AF_INET6 address.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit faaef39a3c)
1) separate HTTP handling from SOAP handling
2) remove repeated validity check, each check is performed exactly once
3) fix HTTP status code per UPnP spec, SOAP spec and RFC 2774
Conflicts:
ChangeLog
upnp/src/soap/soap_device.c
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
SF Bug Tracker #119, Creator: Klaus Fischer
Dear libupnp developers,
I have experienced a crash (access violation) when using libupnp on
Windows. The crash is actually located in pthreads-win32 and happens
when repeatedly de-/initializing libupnp on Win32 in the same process
and both libupnp and pthreads-win32 are compiled as static libraries.
So I'm doing this:
- UpnpInit()
- UpnpFinish()
- UpnpInit() <- Crash
I am already in touch with Ross Johnson on the pthreads-win32 mailing
list regarding this issue:
http://sourceware.org/ml/pthreads-win32/2013/msg00020.html
He told me the problem is that the functions
pthread_win32_process_attach/detach_np() should no longer be called
directly, but are invoked automatically now since version 2.9.0 of
pthreads-win32, which has been released approx. 1.5 years ago. Please
refer to above link for in-depth information.
So for proper using of latest pthreads-win32 library, those function
calls should vanish inside libupnp. Could you consider adapting libupnp
in that way? I would really like to use both libraries out-of-the-box
without local modifications, and this issue prevents that.
Best regards,
Klaus
(cherry picked from commit 2211cc14e6)
SF Bug Tracker #118, Creator: T.Iwamoto
From: gon3456@users.sf.net
Steps to reproduce:
1. Extracts and build libupnp-1.6.18
$ tar -xjf /path/to/archive/libupnp-1.6.18.tar.bz2
$ cd libupnp-1.6.18
$ ./configure
$ make
2. Applies the attached patch and remake.
$ patch -p1 < /path/to/patch/libupnp-1.6.18.patch
$ make
3. Run tv_device.
$ cd upnp/sample
$ ./tv_device
4. Run tv_ctrlpt; the tv_ctrlpt crashes soon.
$ ./tv_ctrlpt
Segmentation fault (core dumped)
This is an issue report about the sample program of control point.
The tv_ctrlpt crashes after detecting a tvdevice that contains tvcontrol:2 or higher version of tvcontrol service.
tv_ctrlpt should detect correctly such devices due to forward compatibility of control points with device.
For more information about the compatibility, please refer the following document:
DLNA Architectures and Protocols Part 1 2011 December - 7.3.2.1.3 (GUN:GZJXU)
The attached patch changes the sample programs as below:
- device: changes version of tvcontrol service from 1 to 2. This change may occur in the future.
- cp: nothing changed: cp knows version 1 of tvcontrol service only.
I know many vendors implements their control points based on the tv_ctrlpt, so I hope to fix this issue ASAP.
==
From: Yoichi NAKAYAMA
SEGV is caused by strcpy with NULL argument.
Attached patch will avoid SEGV in strcpy, but there may be other inconsistencies.
> I know many vendors implements their control points based on the tv_ctrlpt,
I don't think so. I think tv_ctrlpt is just a sample to be used with tv_device.
Signed-off-by: Marcelo Roberto Jimenez <mroberto@users.sourceforge.net>
(cherry picked from commit 1a28e8ff51)
1) Only HTTP_XXX should be return
2) Make default return value work for process_request
(cherry picked from commit 06aa3b17c4)
Conflicts:
upnp/src/genlib/net/http/webserver.c
Hi,
I had found some bugs about memory leak on libupnp-1.6.18.
It may lead to memory leak when calling ThreadPoolAdd() or
ThreadPoolAddPersistent() which does not return 0.
See the attachment for patch.
(cherry picked from commit 8e3a71905b)
Conflicts:
upnp/src/ssdp/ssdp_ctrlpt.c
Suppose the UPnP device is listening on 192.168.1.102:49152. Use the following to send
garbage bytes to the device:
while true; do echo "\""; done | netcat 192.168.1.102 49152
The device just keeps receiving these bytes and its memory usage keeps growing.
Malicious client may exploit it to exhaust the device's memory.
The attached patch eliminates this possibility.
(cherry picked from commit 9a9c4e829e)
1) restore the scanner's original cursor position in case of
insufficient input;
2) free the memories allocated for a new header in case of a failure.
(cherry picked from commit 7a571f513e)
it seems to me that there is still something wrong:
1) the new is_qdtext_char() is incorrect.
There is a trap if char is implemented as signed char.
Suppose that c is '\xFF', it will be -1 when converted to an int.
By definition, c should be qdtext:
qdtext = <any TEXT except <">>
TEXT = <any OCTET except CTLs, but including LWS>
OCTET = <any 8-bit sequence of data>
2) the character after '\\' could be either part of a quoted-pair
(together with '\\'), or a normal qdtext, since '\\' itself can
be treated as a qdtext. This is equivalent to saying that the
character after '\\' in a quoted string could be ANY octet.
A patch based on the above two observations is attached.
Peng
(cherry picked from commit f10730f616)
In soap_ctrlpt.c, in function get_response_value:
upnp_error_code is checked to see if it is less than 400 because that
would indicate a SOAP error code.
However it should be checked to see if it is greater than 400.
(cherry picked from commit 7b1aa4c9e3)
Dear libupnp-devels,
when POST'ing to the simple web server in libupnp, the application crashes.
This is caused by a missing "..." argument in webserver.c:1533.
Seems it has been there for a long time ... 1.6.9 and 1.6.18 have it.
webserver.c:1533 calls http_MakeMessage
/* Send response. */
http_MakeMessage(&headers, 1, 1,
"RTLSXcCc",
ret, "text/html", X_USER_AGENT);
The format parameter RTLSXcCc needs four arguments -
R - response code - ret,
T- content type - text/html,
L - struct SendInstruction * - NOT PRESENT
X - user agent - X_USER_AGENT
This results in a crash.
Changing to
http_MakeMessage(&headers, 1, 1,
"RTLSXcCc",
ret, "text/html", &RespInstr, X_USER_AGENT);
solves the situation.
Yours,
Sebastian Brandt
(cherry picked from commit 25c27b8af7)
upnp/sample/Makefile.am:67: warning: sort \
upnp/sample/Makefile.am:67: $(tv_ctrlpt_SOURCES: non-POSIX variable name
upnp/sample/Makefile.am:67: (probably a GNU make extension)
Reference:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13771#8
(cherry picked from commit dcbbc30f5c)
Reference:
http://lists.gnu.org/archive/html/automake/2012-05/msg00014.html
Re: automake 1.12 and AM_PROG_AR
From: Nick Bowler
Subject: Re: automake 1.12 and AM_PROG_AR
Date: Thu, 10 May 2012 17:16:04 -0400
User-agent: Mutt/1.5.21 (2010-09-15)
On 2012-05-10 12:52 +0200, Simon Josefsson wrote:
> Hi,
>
> I have received patches similar to the one below for several of my
> projects already, and I'm beginning to think there may be something that
> could be improved in automake. Why does automake 1.12 need something
> that 1.11 doesn't even recognize? Perhaps a smoother way to introduce
> this behaviour is to let 1.12 automatically enable it?
>
> Alternatively, is there some other way to address the warnings that is
> better? Does it indicate a real problem in my projects?
>
> http://lists.gnu.org/archive/html/help-libidn/2012-05/msg00000.html
> http://lists.gnu.org/archive/html/help-libidn/2012-05/txtqAGOGgtPqj.txt
FYI, since the patch is so short it would have been helpful to include
it inline in your email. I've taken the liberty of reproducing it
below:
> --- libidn-1.24.orig/configure.ac
> +++ libidn-1.24/configure.ac
> @@ -34,6 +34,10 @@ AC_SUBST(LT_CURRENT, 17)
> AC_SUBST(LT_REVISION, 7)
> AC_SUBST(LT_AGE, 6)
>
> +# automake 1.12 seems to require this, but automake 1.11 doesn't recognize it
> +m4_pattern_allow([AM_PROG_AR])
> +AM_PROG_AR
> +
> AC_PROG_CC
> gl_EARLY
> lgl_EARLY
First off, this patch seems wrong at a first glance by its use of
m4_pattern_allow: this is saying that "It's ok for AM_PROG_AR to appear
verbatim in the configure script". This suggests to me that the patch
didn't actually get tested (well) on Automake 1.11, since there will
almost certainly be an error about AM_PROG_AR at configure time.
This one should actually work properly on both old and new Automake
(untested):
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
That being said, the new warning is enabled by the -Wextra-portability
option that was added to Automake-1.12. I'm by no means an export on
this issue, but I think it relates to new support for building with the
Microsoft compiler: in other words, I think that ignoring this warning
will not cause regressions in your package but, instead, your package
will simply not be able to make use of the new feature.
Regardless, I believe that for most packages the new warning is actually
caused by Libtool, and therefore the correct place to add the call to
AM_PROG_AR is in libtool itself, rather than ad-hoc patching of each
package individually. You can silence the warnings (but not fix them)
by adding -Wno-extra-portability to AM_INIT_AUTOMAKE.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
(cherry picked from commit 3509991872)
This patch addresses three possible buffer overflows in function
unique_service_name(). The three issues have the folowing CVE
numbers:
CVE-2012-5958 Issue #2: Stack buffer overflow of Tempbuf
CVE-2012-5959 Issue #4: Stack buffer overflow of Event->UDN
CVE-2012-5960 Issue #8: Stack buffer overflow of Event->UDN
Notice that the following issues have already been dealt by previous
work:
CVE-2012-5961 Issue #1: Stack buffer overflow of Evt->UDN
CVE-2012-5962 Issue #3: Stack buffer overflow of Evt->DeviceType
CVE-2012-5963 Issue #5: Stack buffer overflow of Event->UDN
CVE-2012-5964 Issue #6: Stack buffer overflow of Event->DeviceType
CVE-2012-5965 Issue #7: Stack buffer overflow of Event->DeviceType
(cherry picked from commit f015a132e8)
