On Tue, Oct 29, 2024 at 12:48:37PM +0000, David Disseldorp wrote:
> When extracting an initramfs cpio archive, the kernel's do_name() path
> handler assumes a zero-terminated path at @collected, passing it
> directly to filp_open() / init_mkdir() / init_mknod().
>
> If a specially crafted cpio entry carries
... /linuxrc with whatever code they want to run as root before anything
else in userland, you are already FUBAR.
> a non-zero-terminated filename
> and is followed by uninitialized memory, then a file may be created with
> trailing characters that represent the uninitialized memory. Symlink
> filename fields handled in do_symlink() won't overrun past the data
> segment, due to the explicit zero-termination of the symlink target.
... or that.
> Fix filename buffer overrun by skipping over any cpio entries where the
> field doesn't carry a zero-terminator at the expected (name_len - 1)
> offset.
>
> Fixes: 1da177e4c3f41 ("Linux-2.6.12-rc2")
> Signed-off-by: David Disseldorp <ddiss@xxxxxxx>
[snip]
> + if (collected[name_len - 1] != '\0') {
> + pr_err("Skipping symlink without nulterm: %.*s\n",
> + (int)name_len, collected);
I'm not sure pr_err() and continue is a good approach here -
you'd been given a corrupted image, so there's no point trying
to do anything further with it. Have it return 1, at least,
and preferably use error("buggered symlink") in addition or
instead of your pr_err().
FWIW, it's _not_ about trying to stop an attack - if you get there with
image contents controlled by attacker, you have already hopelessly lost;
no buffer overruns are needed.
It does catch corrupted images, which is the right thing to do, but it's
not a security issue.
