On Fri, 2019-02-15 at 13:39 +0100, Emilio Pozuelo Monfort wrote:
> On 15/02/2019 13:31, Chris Lamb wrote:
> > Hi Mattias,
> >
> > > I submitted this jessie update to the release team, but was informed to
> > > contact you about it instead. What do I do?
> >
> > Indeed, they have sent you to the right place. :) As-per:
> >
> > https://wiki.debian.org/LTS/Development
> >
> > … we would fix CVE-2019-7659 via a jessie "LTS" security upload.
> >
> > I assume you are not part of the LTS team so you cannot follow the
> > procedure outlined above, but would you object if I took your patch
> > and did the upload and announcement myself?
>
> Before pushing this, I was wondering if the change is safe. It is changing the
> signature of a public symbol. I don't think size_t and int are guaranteed to
> have the same size,
Correct, int is 32-bit on all Debian architectures while size_t is a
native word so 64-bit on 64-bit architectures.
> thus it would be changing the ABI and rdeps would need to be
> rebuilt (in those cases where size_t and int have different sizes). And if we go
> down that slope, then libgsoap needs to bump the SONAME...
That sort of change is not suitable for a stable update.
Given the reference to cookies in the upstream advisory, I think the
actual bug is an integer underflow in soap_putcookies() which results
in passing a very large buffer size to soap_encode_url(). The upstream
patch attempts to fix this by removing the implicit conversion to an
unsigned type and then checking for a negative value.
I think that a portable and ABI-compatible fix would be to add this at
the top of soap_encode_url() instead:
if (len == 0 || len > PTRDIFF_MAX)
return 0;
> Is that right? If so, would it be possible to just change the type to a ssize_t
> instead?
Either that or ptrdiff_t should work.
Ben.
--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson
Attachment:
signature.asc
Description: This is a digitally signed message part