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

Reply via email to