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
next prev parent 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).