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.
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 <jwilk@jwilk.net> ----- Date: Thu, 2 Nov 2017 15:54:39 +0100 From: Jakub Wilk <jwilk@jwilk.net> To: submit@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.----- End forwarded message -----
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 <jwilk@jwilk.net> ----- Date: Thu, 2 Nov 2017 15:54:39 +0100 From: Jakub Wilk <jwilk@jwilk.net> To: submit@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.----- End forwarded message -----