public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: David Disseldorp <ddiss@suse.de>
Cc: linux-fsdevel@vger.kernel.org, Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH] initramfs: avoid filename buffer overrun
Date: Tue, 29 Oct 2024 18:35:20 +0000	[thread overview]
Message-ID: <20241029183520.GE1350452@ZenIV> (raw)
In-Reply-To: <20241029124837.30673-1-ddiss@suse.de>

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@suse.de>

[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.

  reply	other threads:[~2024-10-29 18:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-29 12:48 [PATCH] initramfs: avoid filename buffer overrun David Disseldorp
2024-10-29 18:35 ` Al Viro [this message]
2024-10-30  1:42   ` David Disseldorp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241029183520.GE1350452@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=brauner@kernel.org \
    --cc=ddiss@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox