All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nayna <nayna@linux.vnet.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: tpmdd-devel@lists.sourceforge.net, peterhuewe@gmx.de,
	tpmdd@selhorst.net, jgunthorpe@obsidianresearch.com,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tpm: add buffer access validation in tpm2_get_pcr_allocation()
Date: Mon, 30 Jan 2017 08:28:30 +0530	[thread overview]
Message-ID: <588EABD6.1040500@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170129212020.xz3s4unx5lhxxrgs@intel.com>



On 01/30/2017 02:50 AM, Jarkko Sakkinen wrote:
> On Sun, Jan 29, 2017 at 10:48:39PM +0530, Nayna wrote:
>>
>>
>> On 01/29/2017 08:10 PM, Jarkko Sakkinen wrote:
>>> On Fri, Jan 27, 2017 at 10:25:49AM -0500, Nayna Jain wrote:
>>>> This patch add validation in tpm2_get_pcr_allocation to avoid
>>>> access beyond response buffer length.
>>>>
>>>> Suggested-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
>>>> Signed-off-by: Nayna Jain <nayna@linux.vnet.ibm.com>
>>>
>>> This validation looks broken to me.
>>>
>>>> ---
>>>>    drivers/char/tpm/tpm2-cmd.c | 28 +++++++++++++++++++++++-----
>>>>    1 file changed, 23 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
>>>> index 4aad84c..02c1ea7 100644
>>>> --- a/drivers/char/tpm/tpm2-cmd.c
>>>> +++ b/drivers/char/tpm/tpm2-cmd.c
>>>> @@ -1008,9 +1008,13 @@ static ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
>>>>    	struct tpm2_pcr_selection pcr_selection;
>>>>    	struct tpm_buf buf;
>>>>    	void *marker;
>>>> -	unsigned int count = 0;
>>>> +	void *end;
>>>> +	void *pcr_select_offset;
>>>> +	unsigned int count;
>>>> +	u32 sizeof_pcr_selection;
>>>> +	u32 resp_len;
>>>
>>> Very cosmetic but we almos almost universally use the acronym 'rsp' in
>>> the TPM driver.
>>
>> Sure will update.
>>
>>>
>>>>    	int rc;
>>>> -	int i;
>>>> +	int i = 0;
>>>
>>> Why do you need to initialize it?
>>
>> Because in out: count is replaced with i.
>> And it is replaced because  now for loop can break even before reaching
>> count, because of new buffer checks.
>>>
>>>>
>>>>    	rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_GET_CAPABILITY);
>>>>    	if (rc)
>>>> @@ -1034,15 +1038,29 @@ static ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
>>>>    	}
>>>>
>>>>    	marker = &buf.data[TPM_HEADER_SIZE + 9];
>>>> +
>>>> +	resp_len = be32_to_cpup((__be32 *)&buf.data[2]);
>>>> +	end = &buf.data[resp_len];
>>>
>>> What if the response contains larger length than the buffer size?
>>
>> Isn't this check need to be done in tpm_transmit_cmd for all responses ?
>> Though, it seems it is not done there as well.
>>
>> And to understand what do we expect max buffer length. PAGE_SIZE or
>> TPM_BUFSIZE ?
>
> Oops. You are correct it is done there:
>
> if (len != be32_to_cpu(header->length))
> 	return -EFAULT;
>
> So need to do this.

To be sure, means nothing need to be done in this. Right ?

And guess this was the only thing you meant by broken for this patch.

I will do other two smaller changes as I send the whole new patchset.

Thanks & Regards,
   - Nayna

>
> /Jarkko
>
> /Jarkko
>


  reply	other threads:[~2017-01-30  2:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27 15:25 [PATCH] tpm: add buffer access validation in tpm2_get_pcr_allocation() Nayna Jain
2017-01-27 15:25 ` Nayna Jain
     [not found] ` <1485530749-22948-1-git-send-email-nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-01-29 14:40   ` Jarkko Sakkinen
2017-01-29 14:40     ` Jarkko Sakkinen
     [not found]     ` <20170129144037.sdqd4vutt73isz2i-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2017-01-29 17:18       ` Nayna
2017-01-29 17:18         ` Nayna
     [not found]         ` <588E23EF.2050202-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-01-29 21:20           ` Jarkko Sakkinen
2017-01-29 21:20             ` Jarkko Sakkinen
2017-01-30  2:58             ` Nayna [this message]
2017-01-30 21:47               ` Jarkko Sakkinen

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=588EABD6.1040500@linux.vnet.ibm.com \
    --to=nayna@linux.vnet.ibm.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=peterhuewe@gmx.de \
    --cc=tpmdd-devel@lists.sourceforge.net \
    --cc=tpmdd@selhorst.net \
    /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.