Linux bluetooth development
 help / color / mirror / Atom feed
From: Johan Hedberg <johan.hedberg@gmail.com>
To: Inga Stotland <ingas@codeaurora.org>
Cc: linux-bluetooth@vger.kernel.org, rshaffer@codeaurora.org,
	marcel@holtmann.org
Subject: Re: [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
Date: Thu, 5 Aug 2010 13:25:13 +0300	[thread overview]
Message-ID: <20100805102513.GA7221@jh-x301> (raw)
In-Reply-To: <1280962831-18147-8-git-send-email-ingas@codeaurora.org>

Hi Inga,

On Wed, Aug 04, 2010, Inga Stotland wrote:
> ---
>  src/adapter.c  |  100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
>  src/adapter.h  |    4 +-
>  src/dbus-hci.c |    6 ++--
>  3 files changed, 102 insertions(+), 8 deletions(-)

I've pushed the six other patches upstream, but I'm still a bit
concerned with this one. First there's a minor coding style issue:

> +static char **get_eir_uuids(uint8_t *eir_data, size_t *uuid_count)
> +{
> +	uint8_t len = 0;
> +	char **uuids = NULL;
> +	size_t total = 0;

Neither the uuids nor the total variable need to be initialized upon
declaration if you look at the function's code flow. In general
initialization upon declaration of variables is something that should be
avoided whenever not strictly needed since it can hide real issues that
the compiler would otherwise be able to catch.

Then, a more general concern about this function. It will receive data
as input that any nearby device that's discoverable has declared in
their EIR data. I.e. we need to be super strict about checking the
validity of the data and not make any assumptions about the correctness
of encoded field lengths etc. in order not to do buffer overflows. Have
you taken this into account when designing the function? Looking at it
it seems it might be possible to give it data that will cause some
buffer overflows (by e.g. placing a uuid list at the very end of the EIR
data with an invalid field length value).

Johan

  reply	other threads:[~2010-08-05 10:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-04 23:00 [PATCH v8 0/7] Enhanced support for extended inquiry response Inga Stotland
2010-08-04 23:00 ` [PATCH 1/7] Spec constants for Extended Inquiry Response field types Inga Stotland
2010-08-04 23:00 ` [PATCH 2/7] Minor fix when skipping duplicate UUID16 from EIR Inga Stotland
2010-08-04 23:00 ` [PATCH 3/7] Clean up code that generates extended inquiry response Inga Stotland
2010-08-04 23:00 ` [PATCH 4/7] Support for adding UUID128 to " Inga Stotland
2010-08-04 23:00 ` [PATCH 5/7] Fix in logic to write EIR when SDP records are changed Inga Stotland
2010-08-04 23:00 ` [PATCH 6/7] Handle arrays in device properties dictionary Inga Stotland
2010-08-04 23:00 ` [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal Inga Stotland
2010-08-05 10:25   ` Johan Hedberg [this message]
2010-08-05 21:26     ` ingas
2010-08-05 22:36     ` Inga Stotland
2010-08-06  7:55       ` Johan Hedberg
2010-08-06  7:58         ` Johan Hedberg
2010-08-06 16:16         ` ingas
2010-08-06 17:30           ` Johan Hedberg
2010-08-06 18:18             ` ingas
2010-08-06 18:35             ` Inga Stotland
2010-08-07  3:10               ` Johan Hedberg
  -- strict thread matches above, loose matches on Subject: below --
2010-08-04 17:07 [PATCH v7 0/7] Enhanced support for extended inquiry response Inga Stotland
2010-08-04 17:07 ` [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal Inga Stotland
2010-08-04 19:11   ` Johan Hedberg
2010-08-04  0:03 [PATCH v6 0/7] Enhanced support for extended inquiry response Inga Stotland
2010-08-04  0:03 ` [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal Inga Stotland

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=20100805102513.GA7221@jh-x301 \
    --to=johan.hedberg@gmail.com \
    --cc=ingas@codeaurora.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=rshaffer@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox