linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Tomas Bortoli <tomasbortoli@gmail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	Jaganath Kanakkassery <jaganath.k.os@gmail.com>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	linux-bluetooth@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: hci_event: potential out of bounds parsing ADV events
Date: Mon, 1 Apr 2019 20:41:56 +0300	[thread overview]
Message-ID: <20190401174156.GZ32613@kadam> (raw)
In-Reply-To: <d1b5afe2-8760-55eb-8b6f-28c31b3c3658@gmail.com>

On Mon, Apr 01, 2019 at 07:24:47PM +0200, Tomas Bortoli wrote:
> On 4/1/19 8:32 AM, Dan Carpenter wrote:
> > On Sat, Mar 30, 2019 at 11:44:29PM +0100, Tomas Bortoli wrote:
> >> Hi,
> >>
> >> sorry for the multiple emails but I have checked again the code and
> >> looks like process_adv_report() reads from ev->data for a size of
> >> ev->length.
> >>
> >> I attach a patch that applies the bound check to both
> >> hci_le_ext_adv_report_evt() and hci_le_adv_report_evt().
> >>
> > 
> > You're right that both need to be fixed.
> > 
> >> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> >> index 609fd6871c5a..275926e0753e 100644
> >> --- a/net/bluetooth/hci_event.c
> >> +++ b/net/bluetooth/hci_event.c
> >> @@ -5345,6 +5345,7 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, struct sk_buff *skb)
> >>  {
> >>  	u8 num_reports = skb->data[0];
> >>  	void *ptr = &skb->data[1];
> >> +	u8 *end = &skb->data[skb->len - 1];
> >                              ^^^^^^^^^^^^
> >>  
> >>  	hci_dev_lock(hdev);
> >>  
> >> @@ -5352,6 +5353,9 @@ static void hci_le_adv_report_evt(struct hci_dev *hdev, struct sk_buff *skb)
> >>  		struct hci_ev_le_advertising_info *ev = ptr;
> >>  		s8 rssi;
> >>  
> >> +		if (ev->data + ev->length > end)
> > 
> > No, this isn't right.  You've removed the + 1 and you've introduced an
> > additional "sbk->len - 1" so we're off by two...  The test is supposed
> > to be:
> > 
> > 	start + length_read > start + length_of_buffer
> > 
> 
> afaict: ev->data = start and length_read = ev->length
> and the right side of the condition is the upper limit. "end" as defined
> in my patch is the last readable byte of skb->data (or am I wrong on
> this too?)
> 

You have:

	ptr + length > &skb->data[skb->len - 1];

Imagine we "ptr = &skb->data[skb->len - 1]" that means we can read one
more byte.  But in that case "if (ptr + 1 > &skb->data[skb->len - 1])"
is true so we break instead of allowing the read.  Idiomatically > is
for length and >= is for indexes...

Btw, unrelated but in hci_le_adv_report_evt() if we hit the
HCI_MAX_AD_LENGTH condition we should just break as well.  Everything
after that is going to be guess work and garbage.  No point in trying to
parse it.  IOW:

		if (ptr + sizeof(*ev) + ev->length + 1 > end ||
		    ev->length > HCI_MAX_AD_LENGTH)
			break;

I was planning to resend my patch and the fixes to hci_le_adv_report_evt()
with your Reported-by tonight as two separate patches.  It just makes it
easier to backport if we have a different Fixes tag for both functions.
But then I decided to wait until tomorrow to see if anyone knew what the
+ 1 was about...

regards,
dan carpenter
 

  reply	other threads:[~2019-04-01 17:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-30  7:25 [PATCH] Bluetooth: hci_event: potential out of bounds parsing ADV events Dan Carpenter
2019-03-30  9:20 ` Tomas Bortoli
2019-03-30 22:44   ` Tomas Bortoli
2019-04-01  6:32     ` Dan Carpenter
2019-04-01 17:24       ` Tomas Bortoli
2019-04-01 17:41         ` Dan Carpenter [this message]
2019-04-03  6:54         ` Jaganath K
2019-04-01 18:03   ` Cong Wang
2019-04-02  6:33     ` Dan Carpenter
2019-04-02 17:42       ` Cong Wang
2019-04-02 18:46         ` Tomas Bortoli
2019-04-02 19:55         ` Dan Carpenter
2019-04-03 22:55           ` Cong Wang
2019-04-04  8:06             ` Dan Carpenter
2019-04-05 17:16               ` Cong Wang
2019-04-05 20:48                 ` Dan Carpenter
2019-04-05 21:05                   ` Tomas Bortoli
2019-04-05 21:14                     ` Dan Carpenter
     [not found]                       ` <CAAHj5qj3PciY8ngqSGzH3=TQcm5vCghb0Z_0Y3DFQjTLMUM-9Q@mail.gmail.com>
2019-04-05 21:23                         ` Dan Carpenter
2019-04-02 20:13         ` Dan Carpenter
2019-04-03 22:51           ` Cong Wang
2019-04-04  6:35             ` Dan Carpenter
2019-04-05 16:28               ` Cong Wang

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=20190401174156.GZ32613@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=jaganath.k.os@gmail.com \
    --cc=johan.hedberg@gmail.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=tomasbortoli@gmail.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).