Bug#815965: cpio: reads out-of-bounds with cpio 2.11
hi, On Sun, Jul 29, 2018 at 09:23:49AM +0200, Salvatore Bonaccorso wrote: > Control: tags -1 + patch > > Hi > > Upstream commit fixing the issue should be > > https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=7d55037f89ab630125c37e6fc571cf36bb0a94c3 Though, when applying since there was a previous fix for CVE-2016-2037 which did not land upstream afaics in this form, the commit will not apply cleanly per se and one needs to make sure CVE-2016-2037 is not re-opened. Upstream did apply another fix for CVE-2016-2037: https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=d36ec5f4e93130efb24fb9678aafd88e8070095b There is actually #851632 for the regression caused by our patch for CVE-2016-2037. So probably best approach is to revert our patch and apply the proper upstream patch (and close #851632). Regards, Salvatore
Bug#815965: cpio: reads out-of-bounds with cpio 2.11
Control: tags -1 + patch Hi Upstream commit fixing the issue should be https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=7d55037f89ab630125c37e6fc571cf36bb0a94c3 Regards, Salvatore
Bug#815965: cpio: reads out-of-bounds with cpio 2.11
Control: forwarded -1 http://lists.gnu.org/archive/html/bug-cpio/2015-09/msg2.html Control: tags -1 + patch [Salvatore Bonaccorso] > See http://seclists.org/oss-sec/2016/q1/440 for reproducers (isses can > be uncovered if compiled with ASAN). There is no CVE assigned yet for > those, and as well I think no patch from upstream. I tested with 2.11+dfsg-4.1+deb8u1 and the problematic input file provided from http://seclists.org/oss-sec/2016/q1/att-440/overflow_cpio.bin >, and the problem exist. I notice there is a new upstream version 2.12 available. The problem seem to exist also there: % valgrind ./src/cpio -i < ../cpio-2.11+dfsg/overflow_cpio.bin ==27368== Memcheck, a memory error detector ==27368== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==27368== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==27368== Command: ./src/cpio -i ==27368== ./src/cpio: warning: skipped 8 bytes of junk ==27368== Invalid read of size 1 ==27368==at 0x4041B3: process_copy_in (copyin.c:1382) ==27368==by 0x402AA0: main (main.c:788) ==27368== Address 0x51e52a0 is 0 bytes after a block of size 0 alloc'd ==27368==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==27368==by 0x416818: xmalloc (xmalloc.c:41) ==27368==by 0x403987: read_in_new_ascii (copyin.c:1161) ==27368==by 0x403D87: read_in_header (copyin.c:1038) ==27368==by 0x40419F: process_copy_in (copyin.c:1358) ==27368==by 0x402AA0: main (main.c:788) ==27368== ==27368== Invalid read of size 1 ==27368==at 0x40E07C: safer_name_suffix (names.c:148) ==27368==by 0x40B4D5: cpio_safer_name_suffix (util.c:1419) ==27368==by 0x4041D3: process_copy_in (copyin.c:1388) ==27368==by 0x402AA0: main (main.c:788) ==27368== Address 0x51e52a0 is 0 bytes after a block of size 0 alloc'd ==27368==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==27368==by 0x416818: xmalloc (xmalloc.c:41) ==27368==by 0x403987: read_in_new_ascii (copyin.c:1161) ==27368==by 0x403D87: read_in_header (copyin.c:1038) ==27368==by 0x40419F: process_copy_in (copyin.c:1358) ==27368==by 0x402AA0: main (main.c:788) ==27368== ./src/cpio: Substituting `.' for empty member name ==27368== Invalid write of size 1 ==27368==at 0x4C2D6A3: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:914) ==27368==by 0x4041D3: process_copy_in (copyin.c:1388) ==27368==by 0x402AA0: main (main.c:788) ==27368== Address 0x51e52a0 is 0 bytes after a block of size 0 alloc'd ==27368==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==27368==by 0x416818: xmalloc (xmalloc.c:41) ==27368==by 0x403987: read_in_new_ascii (copyin.c:1161) ==27368==by 0x403D87: read_in_header (copyin.c:1038) ==27368==by 0x40419F: process_copy_in (copyin.c:1358) ==27368==by 0x402AA0: main (main.c:788) ==27368== ==27368== Syscall param lstat(file_name) points to unaddressable byte(s) ==27368==at 0x4F10805: _lxstat (lxstat.c:35) ==27368==by 0x404775: lstat (stat.h:462) ==27368==by 0x404775: try_existing_file (copyin.c:209) ==27368==by 0x404775: copyin_file (copyin.c:704) ==27368==by 0x404775: process_copy_in (copyin.c:1482) ==27368==by 0x402AA0: main (main.c:788) ==27368== Address 0x51e52a0 is 0 bytes after a block of size 0 alloc'd ==27368==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==27368==by 0x416818: xmalloc (xmalloc.c:41) ==27368==by 0x403987: read_in_new_ascii (copyin.c:1161) ==27368==by 0x403D87: read_in_header (copyin.c:1038) ==27368==by 0x40419F: process_copy_in (copyin.c:1358) ==27368==by 0x402AA0: main (main.c:788) ==27368== ./src/cpio: ==27368== Invalid read of size 1 ==27368==at 0x4E7FDCC: vfprintf (vfprintf.c:1642) ==27368==by 0x4E80B00: buffered_vfprintf (vfprintf.c:2348) ==27368==by 0x4E7B37D: vfprintf (vfprintf.c:1296) ==27368==by 0x4F1BAE5: error_tail (error.c:196) ==27368==by 0x4F1BC3D: error (error.c:246) ==27368==by 0x404C25: try_existing_file (copyin.c:233) ==27368==by 0x404C25: copyin_file (copyin.c:704) ==27368==by 0x404C25: process_copy_in (copyin.c:1482) ==27368==by 0x402AA0: main (main.c:788) ==27368== Address 0x51e52a0 is 0 bytes after a block of size 0 alloc'd ==27368==at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==27368==by 0x416818: xmalloc (xmalloc.c:41) ==27368==by 0x403987: read_in_new_ascii (copyin.c:1161) ==27368==by 0x403D87: read_in_header (copyin.c:1038) ==27368==by 0x40419F: process_copy_in (copyin.c:1358) ==27368==by 0x402AA0: main (main.c:788) ==27368== ==27368== Invalid read of size 1 ==27368==at 0x4EAB240: _IO_default_xsputn (genops.c:475) ==27368==by 0x4E7FD86: vfprintf (vfprintf.c:1642) ==27368==by 0x4E80B00: buffered_vfprintf (vfprintf.c:2348) ==27368==by 0x4E7B37D: vfprintf (vfprintf.c:1296) ==27368==by 0x4F1BAE5: error_tail (error.c:196) ==27368==by 0x4F1BC3D: error (error.c:246) ==27368==by 0x404C25: try_existing_file (copyin.c:233) ==27368==
Bug#815965: cpio: reads out-of-bounds with cpio 2.11
Source: cpio Version: 2.11-4 Severity: important Tags: security upstream Hi! See http://seclists.org/oss-sec/2016/q1/440 for reproducers (isses can be uncovered if compiled with ASAN). There is no CVE assigned yet for those, and as well I think no patch from upstream. Regards, Salvatore
