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)
This patch fixes a bug in non blocking connect call where the sock
option length for SO_ERROR was passed as 0 instead of sizeof(int).
(cherry picked from commit 6db2271ac3)
If device is disabled, SetGenaCallback definition is disabled,
but its call remains. A link error will occur in Win32.
(cherry picked from commit 4d21d45da7)
Wrong assignment by shutdown result hides the real error code
of NewRequestHandler() in ssdp_device.c.
Fix return code description of NewRequestHandler().
Handle return code from ithread_create in sample applications.
Remove unused assignments.
(forward ported from commit 39dfad2cba)
Sample applications share sample_util.c and collisions of
object file can occur in parallel build. Modify project files to
split intermediate directories against it.
Apply similar changes also to library projects, like vc10 projects.
(cherry picked from commit e52e7e0bd3)
In parser_parse_chunky_headers, parser->msg.msg.buf can be changed
by membuffer_delete call. Therefore if we save the pointer to
parser->msg.entity.buf before calling membuffer_delete, it will
induce access to released memory.
(cherry picked from commit d72bb5cff5)
Add an additional INET_IPV6 exclusion around IPV6_MULTICAST_HOPS since
the definition isn't guaranteed to exist when the toolchain lacks IPv6
support.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
(cherry picked from commit 1c21e6e54f)
