Fix CVE-2016-2037 (out of bounds write in process_copy_in()). Copied from upstream mailing list: https://lists.gnu.org/archive/html/bug-cpio/2016-01/msg00005.html --- Other calls to cpio_safer_name_suffix seem to be safe. . * src/copyin.c (process_copy_in): Make sure that file_hdr.c_name has at least two bytes allocated. * src/util.c (cpio_safer_name_suffix): Document that use of this function requires to be careful. Author: Pavel Raiskup <praiskup@redhat.com> --- src/copyin.c | 2 ++ src/util.c | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-) Index: cpio-2.11+dfsg/src/copyin.c =================================================================== --- cpio-2.11+dfsg.orig/src/copyin.c +++ cpio-2.11+dfsg/src/copyin.c @@ -1433,6 +1433,8 @@ process_copy_in () break; } + if (file_hdr.c_namesize <= 1) + file_hdr.c_name = xrealloc(file_hdr.c_name, 2); cpio_safer_name_suffix (file_hdr.c_name, false, !no_abs_paths_flag, false); Index: cpio-2.11+dfsg/src/util.c =================================================================== --- cpio-2.11+dfsg.orig/src/util.c +++ cpio-2.11+dfsg/src/util.c @@ -1374,7 +1374,10 @@ set_file_times (int fd, } /* Do we have to ignore absolute paths, and if so, does the filename - have an absolute path? */ + have an absolute path? + Before calling this function make sure that the allocated NAME buffer has + capacity at least 2 bytes to allow us to store the "." string inside. */ + void cpio_safer_name_suffix (char *name, bool link_target, bool absolute_names, bool strip_leading_dots)