archive_read_support_format_rar5.c in libarchive before 3.4.2 attempts to unpack a RAR5 file with an invalid or corrupted header (such as a header size of zero), leading to a SIGSEGV or possibly unspecified other impact
@ maintainer(s): Fixed version is already in repository. Please call for stabilization when ready!
Sure, let's do it.
New vulnerability reported but finalised stabilisation & cleanup here would sort that out.
"archive_read_support_format_lha.c in libarchive before 3.4.1 does not ensure valid sizes for UTF-16 input, which allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted LHA archive."
The bug has been referenced in the following commit(s):
Author: Michał Górny <email@example.com>
AuthorDate: 2020-03-10 16:04:16 +0000
Commit: Michał Górny <firstname.lastname@example.org>
CommitDate: 2020-03-10 16:05:28 +0000
app-arch/libarchive: Remove vulnerable version
Signed-off-by: Michał Górny <email@example.com>
app-arch/libarchive/Manifest | 1 -
.../libarchive-3.4.0-without_zlib_build_fix.patch | 160 ---------------------
app-arch/libarchive/libarchive-3.4.0.ebuild | 135 -----------------
3 files changed, 296 deletions(-)
Added to an existing GLSA request.
@ maintainer(s): This bug will be closed soon when a GLSA was released because cleanup is already done. When you are still interested in stabilization from m68k and sh arch team, please create your own stabilization bug.
This issue was resolved and addressed in
GLSA 202003-28 at https://security.gentoo.org/glsa/202003-28
by GLSA coordinator Thomas Deutschmann (whissi).