mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Rupesh Gujare <rupesh.gujare@atmel.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 13:27:35 +0300	[thread overview]
Message-ID: <20130802102735.GB5051@mwanda> (raw)
In-Reply-To: <1375379102-18217-1-git-send-email-rupesh.gujare@atmel.com>

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.

regards,
dan carpenter

  parent reply	other threads:[~2013-08-02 10:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 17:45 Rupesh Gujare
2013-08-01 17:45 ` [PATCH 6/6] staging: ozwpan: Set farewell report length Rupesh Gujare
2013-08-02 10:27 ` Dan Carpenter [this message]
2013-08-02 11:00   ` [PATCH 5/6] staging: ozwpan: Increase farewell report size Rupesh Gujare
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=20130802102735.GB5051@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=devel@linuxdriverproject.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rupesh.gujare@atmel.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

all inboxes | Powered by JetHome®