[Bug tools/23786] Divide-by-zero Problem in function arlib_add_symbols() in arlib.c in elfutils-0.174
https://sourceware.org/bugzilla/show_bug.cgi?id=23786 alaha changed: What|Removed |Added CC||mda.feedbck at gmail dot com --- Comment #6 from alaha --- Bully Anniversary Edition: https://modandroidapk.com/bully-anniversary-edition/ -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] libelf: decompress: ensure zlib resource cleanup
Hi Matthias,
On Mon, Mar 16, 2020 at 12:42:22AM +0100, Matthias Maennich wrote:
> > Just before this hunk we do:
> >
> > if (likely (zrc == Z_OK))
> >zrc = inflateEnd (&z);
> >
> > So, zrc can be !Z_OK because the earlier inflateEnd() failed, which
> > might cause it to call inflateEnd() twice (which might be fine, I
> > dunno). Should we maybe ignore the error if inflateEnd() and just call
> > it unconditionally before (ignoring its return code)?
> >
> > So, replace:
> > if (... Z_OK) zrc = inflateEnd (&z);
> > with unconditionally ending the stream:
> > (void)inflateEnd(&z);
> >
>
> I prefer your variant (and it was my first version of the patch)
> independently from what comes below.
>
> Having said that: I looked up what inflateEnd() does and the worst that
> could happen is returning an error that we anyway ignore. So, duplicate
> calls are not an issue. Also, for the compression part we call
> deflateEnd() via a macro in the same duplicate fashion. Hence I
> consistently used the same pattern for inflateEnd(). And last, I wanted
> to keep that existing error handling. OTOH, projects (including the
> example code of zlib [1]) usually just unconditionally call inflateEnd()
> ignoring any error codes. So, your call :-)
Thanks for looking into this so closely. I think it is best to just do
as the example code does. Always call inflateEnd (), ignoring the
return code and not care whether (in an error case) it might be called
twice. And to make it consistent in this file. So:
diff --git a/libelf/elf_compress.c b/libelf/elf_compress.c
index 244467b5..32422edc 100644
--- a/libelf/elf_compress.c
+++ b/libelf/elf_compress.c
@@ -197,7 +197,7 @@ __libelf_compress (Elf_Scn *scn, size_t hsize, int ei_data,
}
while (flush != Z_FINISH); /* More data blocks. */
- zrc = deflateEnd (&z);
+ deflateEnd (&z);
if (zrc != Z_OK)
{
__libelf_seterrno (ELF_E_COMPRESS_ERROR);
@@ -251,8 +251,7 @@ __libelf_decompress (void *buf_in, size_t size_in, size_t
size_out)
}
zrc = inflateReset (&z);
}
- if (likely (zrc == Z_OK))
-zrc = inflateEnd (&z);
+ inflateEnd (&z);
if (unlikely (zrc != Z_OK) || unlikely (z.avail_out != 0))
{
Thanks,
Mark
Re: [PATCH] libelf: decompress: ensure zlib resource cleanup
Hi,
On Mon, Mar 16, 2020 at 01:05:26PM +0100, Mark Wielaard wrote:
> Thanks for looking into this so closely. I think it is best to just do
> as the example code does. Always call inflateEnd (), ignoring the
> return code and not care whether (in an error case) it might be called
> twice. And to make it consistent in this file. So:
>
> diff --git a/libelf/elf_compress.c b/libelf/elf_compress.c
> index 244467b5..32422edc 100644
> --- a/libelf/elf_compress.c
> +++ b/libelf/elf_compress.c
> @@ -197,7 +197,7 @@ __libelf_compress (Elf_Scn *scn, size_t hsize, int
> ei_data,
> }
>while (flush != Z_FINISH); /* More data blocks. */
>
> - zrc = deflateEnd (&z);
> + deflateEnd (&z);
>if (zrc != Z_OK)
> {
>__libelf_seterrno (ELF_E_COMPRESS_ERROR);
> @@ -251,8 +251,7 @@ __libelf_decompress (void *buf_in, size_t size_in, size_t
> size_out)
> }
>zrc = inflateReset (&z);
> }
> - if (likely (zrc == Z_OK))
> -zrc = inflateEnd (&z);
> + inflateEnd (&z);
>
>if (unlikely (zrc != Z_OK) || unlikely (z.avail_out != 0))
> {
Obviously, I didn't look that closely, because when you apply the
above it causes multiple testcase failures. Oops. Sorry, back to the
drawing board. I suspect the zrz = deflateEnd in the compress case is
different from inflateEnd in the decompress case...
Cheers,
Mark
[Bug tools/23787] eu-size: Bad handling of ar files inside are files
https://sourceware.org/bugzilla/show_bug.cgi?id=23787 --- Comment #14 from Bartan Muhman --- Here they have shared the solution for the issue. I am not that sure how effective it will be it worked fine on one of my favorite android games! Here is a link to it - https://appmirror.net/games/action/grand-theft-auto-vice-city-apk-10-39317/ -- You are receiving this mail because: You are on the CC list for the bug.
