Hi, Jakub Wilk also reported to the Debian bug tracking system that unar crashes when it's run on the attached file. The full text of the report can be found below.
I will also attempt to reproduce this problem using The Unarchiver on Monday. ----- Forwarded message from Jakub Wilk <jw...@jwilk.net> ----- Date: Thu, 2 Nov 2017 15:54:39 +0100 From: Jakub Wilk <jw...@jwilk.net> To: sub...@bugs.debian.org Subject: Bug#880585: unar: unbounded VLA in -[XADArParser parse] User-Agent: NeoMutt/20170609 (1.8.3) Package: unar Version: 1.10.1-2+b1 lsar crashes on the attached file: $ lsar bigvla.ar bigvla.ar: Segmentation fault GDB says it's because it tried to create a very big variable-length array: (gdb) bt #0 0x565abace in -[XADArParser parse] (self=<optimized out>, _cmd=0x56746880 <_OBJC_SELECTOR_TABLE+1120>) at XADArParser.m:69 #1 0x565b0bf1 in -[XADArchiveParser parseWithoutExceptions] (self=0x56893738, _cmd=0x56777ff0 <_OBJC_SELECTOR_TABLE+368>) at XADArchiveParser.m:1199 #2 0x56614c86 in -[XADSimpleUnarchiver parse] (self=0x56896168, _cmd=0x56735ac0 <_OBJC_SELECTOR_TABLE+352>) at XADSimpleUnarchiver.m:324 #3 0x5658ead9 in main (argc=<optimized out>, argv=<optimized out>) at unar.m:250 (gdb) list -3,+3 66 // BSD long filename. 67 int namelen=(int)ParseDecimal(&header[3],12); 68 uint8_t namebuf[namelen]; 69 [fh readBytes:namelen toBuffer:namebuf]; (gdb) print namelen $1 = 1215752192 VLAs are allocated on stack, which is not _that_ big. -- System Information: Architecture: i386 Versions of packages unar depends on: ii dpkg 1.19.0.4 ii gnustep-base-runtime 1.25.0-2 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-17 ii libgcc1 1:7.2.0-12 ii libgnustep-base1.25 1.25.0-2 ii libicu57 57.1-8 ii libobjc4 7.2.0-12 ii libstdc++6 7.2.0-12 ii libwavpack1 5.1.0-2 ii zlib1g 1:1.2.8.dfsg-5 -- Jakub Wilk ----- End forwarded message ----- -- Matt
!<arch> #1/1000000000000000000000000000000000000000000000000000000`
