linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Peter Jones <pjones@redhat.com>,
	intel-gfx@lists.freedesktop.org,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Jason Andryuk <jandryuk@gmail.com>,
	Matthew Garrett <mjg59@coreos.com>,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib: Always NUL terminate ucs2_as_utf8
Date: Wed, 20 Apr 2016 14:45:04 +0200	[thread overview]
Message-ID: <571779D0.1040508@redhat.com> (raw)
In-Reply-To: <20160420094133.GF14602@nuc-i3427.alporthouse.com>

On 04/20/16 11:41, Chris Wilson wrote:
> On Wed, Apr 20, 2016 at 11:36:37AM +0200, Laszlo Ersek wrote:
>> On 04/20/16 10:37, Chris Wilson wrote:
>>> If the caller, in this case efivarfs_callback(), only provides sufficent
>>> room for the expanded utf8 and not enough to include the terminating NUL
>>> byte, that NUL byte is skipped.
>>
>> How does that occur? In efivarfs_callback() [fs/efivarfs/super.c], we have
>>
>> 	len = ucs2_utf8size(entry->var.VariableName);
>>
>> 	/* name, plus '-', plus GUID, plus NUL*/
>> 	name = kmalloc(len + 1 + EFI_VARIABLE_GUID_LEN + 1, GFP_KERNEL);
>> 	if (!name)
>> 		goto fail;
>>
>> 	ucs2_as_utf8(name, entry->var.VariableName, len);
>>
>> Instead, I think the following might be happening (note that RIP points
>> into efivar_variable_is_removable(), and I guess variable_matches()
>> (which is static) is inlined):
>>
>> efivarfs_callback()              [fs/efivarfs/super.c]
>>   efivar_variable_is_removable() [drivers/firmware/efi/vars.c]
>>     variable_matches()           [drivers/firmware/efi/vars.c]
>>
>> The bug seems to be in variable_matches(), which doesn't consider the
>> "len" parameter early enough. Namely, consider that we have the
>> following input:
>>
>> - var_name: "a"
>> - len: 1
>> - match_name "ab"
>>
>> In the first iteration of the loop (i.e., *match == 0):
>> - c = 'a'
>> - u = 'a'
>> - *match gets incremented to 1.
>>
>> In the second iteration of the loop (i.e., *match == 1):
>> - c = 'b'
>> - u = <indeterminate value> (that is, undefined behavior),
>>   because (*match == len).
>>
>> This seems to be consistent with the error message "Caught 8-bit read
>> from uninitialized memory": namely, the array allocated for "name" in
>> efivarfs_callback() is indeed not pre-zeroed, and the ucs2_as_utf8()
>> function does not populate name[len] -- correctly, I would say.
> 
> ucs2_as_utf8 reports that it returns a NUL terminated string.

I don't think it does. Here's the comment:

/*
 * copy at most maxlength bytes of whole utf8 characters to dest from the
 * ucs2 string src.
 *
 * The return value is the number of characters copied, not including the
 * final NUL character.
 */

It doesn't seem to promise that the output will always be NUL-terminated. And, the code explicitly considers the case when there is no room for the final NUL.

A strictly NUL-terminated output might make for a better interface, but then the comment should be updated as well. Plus, I'm unsure if it would be aligned with Peter's original goal (and the current call sites). I'm not against changing the interface contract; I'll let Peter speak up.

> It didn't
> in this case.
> -Chris
> 

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-04-20 12:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  8:37 [PATCH] lib: Always NUL terminate ucs2_as_utf8 Chris Wilson
     [not found] ` <1461141427-16361-1-git-send-email-chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
2016-04-20  9:36   ` Laszlo Ersek
2016-04-20  9:41     ` Chris Wilson
2016-04-20 12:45       ` Laszlo Ersek [this message]
2016-04-20 13:25   ` Laszlo Ersek
     [not found]     ` <5717834C.6070802-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-04-21 12:18       ` Matt Fleming
2016-04-21 15:13         ` Peter Jones
2016-04-21 16:21         ` Laszlo Ersek
2016-04-22 18:52           ` Matt Fleming
     [not found]             ` <20160422185210.GG2829-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2016-04-25 10:17               ` Laszlo Ersek
2016-04-20 14:03   ` [Intel-gfx] " Jani Nikula

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=571779D0.1040508@redhat.com \
    --to=lersek@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jandryuk@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mjg59@coreos.com \
    --cc=pjones@redhat.com \
    /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;
as well as URLs for NNTP newsgroup(s).