public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hedberg <johan.hedberg@gmail.com>
To: Matias Karhumaa <matias.karhumaa@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH] obexd: Fix null pointer dereference.
Date: Wed, 21 Jun 2017 12:41:48 +0300	[thread overview]
Message-ID: <20170621094148.GA27878@x1c> (raw)
In-Reply-To: <20170621061358.GA17661@makarhum-e6330>

Hi Matias,

On Wed, Jun 21, 2017, Matias Karhumaa wrote:
> By sending OPP Put request before CONNECT we were able to cause
> SIGSEGV in obexd. Crash was caused by null pointer dereference.
> 
> gdb output:
> 
> Program received signal SIGSEGV, Segmentation fault.
> manager_request_authorization (transfer=transfer@entry=0x0, new_folder=new_folder@entry=0x7fffffffda18, new_name=new_name@entry=0x7fffffffda20) at obexd/src/manager.c:677
> 677		struct obex_session *os = transfer->session;
> (gdb) bt
> *#0  manager_request_authorization (transfer=transfer@entry=0x0, new_folder=new_folder@entry=0x7fffffffda18, new_name=new_name@entry=0x7fffffffda20) at obexd/src/manager.c:677
> *#1  0x000000000041b7a5 in opp_chkput (os=0x67de60, user_data=0x0) at obexd/plugins/opp.c:80
> *#2  0x0000000000426cc5 in check_put (obex=0x678a50, req=0x679250, user_data=0x67de60) at obexd/src/obex.c:831
> *#3  cmd_put (obex=0x678a50, req=0x679250, user_data=0x67de60) at obexd/src/obex.c:887
> *#4  0x00000000004145e7 in handle_request (req=0x679250, obex=0x678a50) at gobex/gobex.c:1199
> *#5  incoming_data (io=<optimized out>, cond=<optimized out>, user_data=0x678a50) at gobex/gobex.c:1375
> *#6  0x00007ffff749204a in g_main_dispatch (context=0x674810) at /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c:3154
> *#7  g_main_context_dispatch (context=context@entry=0x674810) at /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c:3769
> *#8  0x00007ffff74923f0 in g_main_context_iterate (context=0x674810, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
>     at /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c:3840
> *#9  0x00007ffff7492712 in g_main_loop_run (loop=0x66fdf0) at /build/glib2.0-prJhLS/glib2.0-2.48.2/./glib/gmain.c:4034
> *#10 0x000000000040dd0f in main (argc=1, argv=0x7fffffffde08) at obexd/src/main.c:322
> 
> Crash was found using Synopsys Defensics Obex Server test suite.
> ---
>  obexd/src/obex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/obexd/src/obex.c b/obexd/src/obex.c
> index 788bffc..91fa838 100644
> --- a/obexd/src/obex.c
> +++ b/obexd/src/obex.c
> @@ -825,7 +825,7 @@ static gboolean check_put(GObex *obex, GObexPacket *req, void *user_data)
>  	struct obex_session *os = user_data;
>  	int ret;
>  
> -	if (os->service->chkput == NULL)
> +	if (os->service->chkput == NULL || os->service_data == NULL)
>  		goto done;

As far as I understand, os->service_data is the OBEX service-specific
context, which I think can in principle validly be NULL. Also, isn't it
so that OBEX Object Push permits PUT without a preceding CONNECT (at
least that's what I remember from the times I was working with OBEX)?

It seems to me that the bug is with opp.c passing the service_data to
manager_request_authorization(), and service_data is expected to be the
obex_transfer object. However, currently the code creates this object
only upon CONNECT (in opp_connect).

I think one possible way to solve this would be to trigger a call to
os->service->connect if CONNECT hasn't been explicitly issued, however
then the code needs to track this in some other way since service_data
seems too unreliable.

Johan

  reply	other threads:[~2017-06-21  9:41 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21  6:14 [PATCH] obexd: Fix null pointer dereference Matias Karhumaa
2017-06-21  9:41 ` Johan Hedberg [this message]
2017-06-21 17:36   ` Luiz Augusto von Dentz
2017-06-21 19:31     ` Luiz Augusto von Dentz
2017-06-22  4:32       ` Matias Karhumaa
2017-06-22  6:18         ` Johan Hedberg
2017-06-22 10:20           ` Matias Karhumaa

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=20170621094148.GA27878@x1c \
    --to=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=matias.karhumaa@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