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
signature.asc
Description: This is a digitally signed message part
