All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rupesh Gujare <rupesh.gujare@atmel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <devel@linuxdriverproject.org>, <gregkh@linuxfoundation.org>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/6] staging: ozwpan: Increase farewell report size.
Date: Fri, 2 Aug 2013 12:00:44 +0100	[thread overview]
Message-ID: <51FB915C.1050003@atmel.com> (raw)
In-Reply-To: <20130802102735.GB5051@mwanda>

On 02/08/13 11:27, Dan Carpenter wrote:
> On Thu, Aug 01, 2013 at 06:45:01PM +0100, Rupesh Gujare wrote:
>> Farewell report size can be bigger than one byte, increase array
>> size to accomodate maximum 32 bytes of farewell report.
>>
> Gar...  No.  This is not right.
>
> 1) There is no check limiting the size to 32 and it could be up to
>     253 bytes.
>
> 2) Use defines instead of magic numbers.
>
> 3) The oz_farewell struct is supposed to be a variable length struct
>     but the variable part is put in the middle.  It doesn't make any
>     sense to put the length of the variable size array after then end
>     of the array because we can never find it again!  Put the
>     variable size array at the end.  Make it a zero length array.
>     u8 len;
>     u8 report[0];
>
> 4) In oz_add_farewell() we do this:
>
> 	f = kmalloc(sizeof(struct oz_farewell) + len - 1, GFP_ATOMIC);
>
>      The "- 1" refers to sizeof(f->report) but because it was a magic
>      number then it was missed when the sizeof(f->report) changed.
>
> 5) In [patch 6/6] we set the ->len member.  But because it is at the
>     end of a variable length array with no limit check the remote
>     attacker can just rewrite it using the memcpy() on the next line.
>
>
Thanks Dan.

A patch follows to fix above issues.

-- 
Regards,
Rupesh Gujare


  reply	other threads:[~2013-08-02 11:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 17:45 [PATCH 5/6] staging: ozwpan: Increase farewell report size Rupesh Gujare
2013-08-01 17:45 ` [PATCH 6/6] staging: ozwpan: Set farewell report length Rupesh Gujare
2013-08-02 10:27 ` [PATCH 5/6] staging: ozwpan: Increase farewell report size Dan Carpenter
2013-08-02 11:00   ` Rupesh Gujare [this message]
2013-08-02 11:04     ` [PATCH] staging: ozwpan: Fix farewell report Rupesh Gujare
2013-08-03  3:10       ` Greg KH
2013-08-05 11:28         ` [PATCH v2] " Rupesh Gujare

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=51FB915C.1050003@atmel.com \
    --to=rupesh.gujare@atmel.com \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@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 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.