`unar` and `lsar -t` sometimes segfault on certain files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
unar (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
While trying to unpack some .ARC files from a 1980s "shareware of the month"-style 5.25" floppy disk, I got `lsar -t` to segfault and then `unar`.
I was unable to trigger it in a brand new build made from a fresh download of the upstream TheUnarchiverSo
However, identifying WHAT was fixed may be difficult because I was also unable to trigger it when running under gdb to attempt a backtrace, and, of the four .ARC files on the floppy disk, which ones work and which ones segfault vary from run to run and `unar` may work while `lsar -t` segfaults or vice-versa.
I suspect it's caused by reading from uninitialized memory.
The original archival tool reports success with no corruption for all of them when run under DOSBox and since the DOS extractor is freeware and the archives' contents are all either freeware or shareware (and the entire floppy was just 360K), I'll attach them to the bug report in case anyone wants to run their own testing.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: unar 1.10.1-2build7
ProcVersionSign
Uname: Linux 5.8.0-63-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.11-
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: KDE
Date: Fri Sep 17 13:57:52 2021
SourcePackage: unar
UpgradeStatus: No upgrade log present (probably fresh install)
Changed in unar (Ubuntu): | |
status: | New → Fix Released |
can you try the latest version?