I can't reproduce it. I created 7.9G archive successfully.

can you reproduce this with the debuginfo rpm installed?

Installed the debuginfo rpm, and ran it under gdb. Here's the results:

Program received signal SIGABRT, Aborted.
0x0000003a2e52f280 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003a2e52f280 in raise () from /lib64/libc.so.6
#1  0x0000003a2e530750 in abort () from /lib64/libc.so.6
#2  0x0000003a2e564a7f in __libc_message () from /lib64/libc.so.6
#3  0x0000003a2e5dcb6f in __chk_fail () from /lib64/libc.so.6
#4  0x0000003a2e5dc149 in _IO_str_chk_overflow () from /lib64/libc.so.6
#5  0x0000003a2e567b26 in _IO_default_xsputn_internal () from /lib64/libc.so.6
#6  0x0000003a2e55d532 in _IO_padn_internal () from /lib64/libc.so.6
#7  0x0000003a2e541bca in vfprintf () from /lib64/libc.so.6
#8  0x0000003a2e5dc1f9 in __vsprintf_chk () from /lib64/libc.so.6
#9  0x0000003a2e5dc130 in __sprintf_chk () from /lib64/libc.so.6
#10 0x000000000040534f in write_out_header (file_hdr=0x7fffffb189e0, out_des=1)
at copyout.c:307
#11 0x0000000000405ab9 in process_copy_out () at copyout.c:646
#12 0x0000000000407e3f in main (argc=3, argv=0x7fffffb18bc8) at main.c:765
#13 0x0000003a2e51c3cf in __libc_start_main () from /lib64/libc.so.6
#14 0x0000000000402729 in _start ()
#15 0x00007fffffb18bb8 in ?? ()
#16 0x0000000000000000 in ?? ()

Does it work with cpio < 2.6-8.FC4

Tested it with cpio-2.6-7.x86_64.rpm, from the FC4 installation disc, and it
aborts as well.

======= Backtrace: =========
/lib64/libc.so.6(__chk_fail+0x2f)[0x3a2e5dcb6f]
/lib64/libc.so.6[0x3a2e5dc149]
/lib64/libc.so.6(_IO_default_xsputn+0x86)[0x3a2e567b26]
/lib64/libc.so.6(_IO_padn+0x62)[0x3a2e55d532]
/lib64/libc.so.6(_IO_vfprintf+0xf2a)[0x3a2e541bca]
/lib64/libc.so.6(__vsprintf_chk+0xa9)[0x3a2e5dc1f9]
/lib64/libc.so.6(__sprintf_chk+0x80)[0x3a2e5dc130]
/tmp/cpio/bin/cpio[0x405370]
/tmp/cpio/bin/cpio[0x405ad9]
/tmp/cpio/bin/cpio[0x407def]
/lib64/libc.so.6(__libc_start_main+0xef)[0x3a2e51c3cf]
/tmp/cpio/bin/cpio[0x402729]

I found the file causing the problem:

[root@dr1 ~]# ls -la /var/log/lastlog
-rw-r--r--  1 root root 1254130450140 Nov  9 11:23 /var/log/lastlog

It looks like the file's size was corrupted at some point. Telling cpio to
backup just this one file is enough to kill it immediately.

      char ascii_header[112];
...
      sprintf (ascii_header,
              
"%6s%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx%08lx",
               magic_string,
               file_hdr->c_ino, file_hdr->c_mode, file_hdr->c_uid,
               file_hdr->c_gid, file_hdr->c_nlink, file_hdr->c_mtime,
             file_hdr->c_filesize, file_hdr->c_dev_maj, file_hdr->c_dev_min,
           file_hdr->c_rdev_maj, file_hdr->c_rdev_min, file_hdr->c_namesize,
               file_hdr->c_chksum);

...

cpio assumes the filesize is at most 8 digits in size... and that's not right.
If it's more, this buffer will indeed overflow....

this probably wants to use asprintf() or so

This issue should also affect FC3.

Please note that this is only a security issue on 64 bit platforms.

Created attachment 121061 [details]
fix from upstream

(write_out_header): Rewritten using separate
functions for each file format. Use to_ascii to convert numbers to
ascii representation. Check for overflows and report them if
appropriate. Return 0 if it is OK to proceed with archiving this
file, 1 otherwise. All callers updated.

cpio-2.6.9-11
cpio-2.6-9.FC4

It's unclear to me if this was ever fixed in RHEL4. It definitely wasn't in FC3.

I don't think security issues should be resolved as CLOSED:RAWHIDE.

Created attachment 148862 [details]
patch fixing buffer overflow on 64bit systems for cpio-2.5

I'm confused.  For what distribution is this patch in comment #12 to be
applied?  FC3 is no longer supported.

Should this bug be "CLOSED WONTFIX"?  Or reassigned to another product?

this patch can be applied on cpio-2.5 in FC-3

FC3 is not longer supported, bug is resolved in FC5 and FC6