summaryrefslogtreecommitdiff
path: root/usr/gen_init_cpio.c
AgeCommit message (Collapse)AuthorFilesLines
2013-11-13gen_init_cpio: avoid NULL pointer dereference and rework env expandingMichal Nazarewicz1-18/+9
getenv() may return NULL if given environment variable does not exist which leads to NULL dereference when calling strncat. Besides that, the environment variable name was copied to a temporary env_var buffer, but this copying can be avoided by simply using the input string. Lastly, the whole loop can be greatly simplified by using the snprintf function instead of the playing with strncat. By the way, the current implementation allows a recursive variable expansion, as in: $ echo 'out ${A} out ' | A='a ${B} a' B=b /tmp/a out a b a out I'm assuming this is just a side effect and not a conscious decision (especially as this may lead to infinite loop), but I didn't want to change this behaviour without consulting. If the current behaviour is deamed incorrect, I'll be happy to send a patch without recursive processing. Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Cc: Kees Cook <keescook@chromium.org> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Jesper Juhl <jj@codesealer.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-11-19gen_init_cpio: remove redundant empty lineJesper Juhl1-1/+0
Just a completely trivial patch to remove a completely redundant blank line from usr/gen_init_cpio.c Signed-off-by: Jesper Juhl <jj@codesealer.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-10-26gen_init_cpio: avoid stack overflow when expandingKees Cook1-20/+23
Fix possible overflow of the buffer used for expanding environment variables when building file list. In the extremely unlikely case of an attacker having control over the environment variables visible to gen_init_cpio, control over the contents of the file gen_init_cpio parses, and gen_init_cpio was built without compiler hardening, the attacker can gain arbitrary execution control via a stack buffer overflow. $ cat usr/crash.list file foo ${BIG}${BIG}${BIG}${BIG}${BIG}${BIG} 0755 0 0 $ BIG=$(perl -e 'print "A" x 4096;') ./usr/gen_init_cpio usr/crash.list *** buffer overflow detected ***: ./usr/gen_init_cpio terminated This also replaces the space-indenting with tabs. Patch based on existing fix extracted from grsecurity. Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Michal Marek <mmarek@suse.cz> Cc: Brad Spengler <spender@grsecurity.net> Cc: PaX Team <pageexec@freemail.hu> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-04-18initramfs: Use KBUILD_BUILD_TIMESTAMP for generated entriesMichal Marek1-13/+40
gen_init_cpio gets the current time and uses it for each symlink, special file, and directory. Grab the current time once and make it possible to override it with the KBUILD_BUILD_TIMESTAMP variable for reproducible builds. Signed-off-by: Michal Marek <mmarek@suse.cz>
2011-01-06gen_init_cpio: checkpatch fixesAndrew Morton1-2/+2
Cc: Jesper Juhl <jj@chaosbits.net> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-12-29gen_init_cpio: Avoid race between call to stat() and call to open()Jesper Juhl1-6/+6
In usr/gen_init_cpio.c::cpio_mkfile() a call to stat() is made based on pathname, subsequently the file is open()'ed and then the value of the initial stat() call is used to allocate a buffer. This is not safe since the file may change between the call to stat() and the call to open(). Safer to just open() the file and then do fstat() using the filedescriptor returned by open. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Acked-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-12-02gen_init_cpio: remove leading `/' from file namesThomas Chou1-0/+8
When we extracted the generated cpio archive using "cpio -id" command, it complained, cpio: Removing leading `/' from member names var/run cpio: Removing leading `/' from member names var/lib cpio: Removing leading `/' from member names var/lib/misc It is worse with the latest "cpio" or "pax", which tries to overwrite the host file system with the leading '/'. So the leading '/' of file names should be removed. This is consistent with the initramfs come with major distributions such as Fedora or Debian, etc. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> Acked-by: Mike Frysinger<vapier@gentoo.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-12-12gen_init_cpio: fixed fwrite warningMike Frysinger1-1/+4
On compilers with security warnings enabled by default, we get: usr/gen_init_cpio.c: In function ‘cpio_mkfile’: usr/gen_init_cpio.c:357: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result So check the return value and handle errors accordingly. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michal Marek <mmarek@suse.cz>
2009-09-23Fix all -Wmissing-prototypes warnings in x86 defconfigTrevor Keith1-1/+1
Signed-off-by: Trevor Keith <tsrk@tsrk.net> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-12-03kbuild: gen_init_cpio expands shell variables in file namesSally, Gene1-1/+27
Modify gen_init_cpio so that lines that specify files can contain what looks like a shell variable that's expanded during processing. For example: file /sbin/kinit ${RFS_BASE}/usr/src/klibc/kinit/kinit 0755 0 0 given RFS_BASE is "/some/directory" in the environment would be expanded to file /sbin/kinit /some/directory/usr/src/klibc/kinit/kinit 0755 0 0 If several environment variables appear in a line, they are all expanded with processing happening from left to right. Undefined variables expand to a null string. Syntax errors stop processing, letting the existing error handling show the user offending line. This patch helps embedded folks who frequently create several RFS directories and then switch between them as they're tuning an initramfs. Signed-off-by: gene.sally@timesys.com Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-07-16kbuild: add support for reading stdin with gen_init_cpioMike Frysinger1-1/+3
Treat an argument of "-" as meaning "read stdin for cpio files" so gen_init_cpio can be piped into. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-02-11[PATCH] usr/gen_init_cpio.c: support for hard linksLuciano Rocha1-36/+86
Extend usr/gen_init_cpio.c "file" entry, adding support for hard links. Previous format: file <name> <location> <mode> <uid> <gid> New format: file <name> <location> <mode> <uid> <gid> [<hard links>] The hard links specification is optional, keeping the previous behaviour. All hard links are defined sequentially in the resulting cpio and the file data is present only in the last link. This is the behaviour of GNU's cpio and is supported by the kernel initramfs extractor. Signed-off-by: Luciano Rocha <strange@nsk.no-ip.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-04-19[PATCH] Fix potential NULL pointer deref in gen_init_cpioJesper Juhl1-1/+3
Fix potential NULL pointer deref in gen_init_cpio.c spotted by coverity checker. This fixes coverity bug #86 Without this patch we risk dereferencing a NULL `type' in the "if ('\n' == *type) {" line. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-17Linux-2.6.12-rc2Linus Torvalds1-0/+512
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!