From: Tyler Hicks <tyhicks@canonical.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Halcrow <mhalcrow@google.com>,
ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
thieule@google.com
Subject: Re: [PATCH] eCryptfs: Check array bounds for filename characters
Date: Wed, 23 Nov 2011 11:03:59 -0600 [thread overview]
Message-ID: <20111123170350.GA24836@boyd> (raw)
In-Reply-To: <CA+55aFw1XMbJTBifw1sSUN-7cC2BdeeZwPrqkxsboAo6SFSoNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]
On 2011-11-21 16:49:07, Linus Torvalds wrote:
> On Mon, Nov 21, 2011 at 3:32 PM, Michael Halcrow <mhalcrow@google.com> wrote:
> > Characters with ASCII values greater than the size of
> > filename_rev_map[] are valid filename
> > characters. ecryptfs_decode_from_filename() will access kernel memory
> > beyond that array, and ecryptfs_parse_tag_70_packet() will then
> > decrypt those characters.
>
> Ugh. I really don't like the patch.
>
> Why isn't the patch just this one-liner:
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index 58609bde3b9f..7c50715c05d6 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -1943,7 +1943,7 @@ static unsigned char *portable_filename_chars
> = ("-.0123456789ABCD"
>
> /* We could either offset on every reverse map or just pad some 0x00's
> * at the front here */
> -static const unsigned char filename_rev_map[] = {
> +static const unsigned char filename_rev_map[256] = {
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 7 */
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 15 */
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 23 */
>
> instead?
>
> Making invalid characters over \x50 be somehow magically different
> from invalid characters elsewhere seems just totally bogus. There are
> lots of characters that aren't valid, and they have the
> filename_rev_map[] value of 0 elsewhere.
>
> So the simpler one-liner is not only simpler, but gives much saner
> semantics, I think - now invalid character '\x05' gets exactly the
> same result as invalid character '\xf5'.
Good point - I'll get this in proper patch form and send a pull request
your way, along with a couple of other fixes.
Tyler
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2011-11-23 17:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 23:32 [PATCH] eCryptfs: Check array bounds for filename characters Michael Halcrow
2011-11-21 23:46 ` Tyler Hicks
2011-11-22 0:49 ` Linus Torvalds
2011-11-23 17:03 ` Tyler Hicks [this message]
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=20111123170350.GA24836@boyd \
--to=tyhicks@canonical.com \
--cc=ecryptfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=thieule@google.com \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.