public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* sdp update record
@ 2009-07-20  8:46 josem
  2009-07-21 18:02 ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 2+ messages in thread
From: josem @ 2009-07-20  8:46 UTC (permalink / raw)
  To: linux-bluetooth

Hi everyone 

Working with BlueZ 4.46, bluetoothd process makes an segfault when an 
"update sdp record" request is processed. Running with valgrind memcheck 
I checked that when an "search attr" request arrives after the "update sdp 
record",
 this record handle not exists because this memory has been freed in the 
"update sdp record" stage. The code block when "update spd record" is made 

is below: 


int service_update_req(sdp_req_t *req, sdp_buf_t *rsp)
{
        sdp_record_t *orec;
        int status = 0, scanned = 0;
        uint8_t *p = req->buf + sizeof(sdp_pdu_hdr_t);
        int bufsize = req->len - sizeof(sdp_pdu_hdr_t);
        uint32_t handle = ntohl(bt_get_unaligned((uint32_t *) p));

        SDPDBG("Svc Rec Handle: 0x%x", handle);

        p += sizeof(uint32_t);
        bufsize -= sizeof(uint32_t);

        orec = sdp_record_find(handle);

        SDPDBG("SvcRecOld: %p", orec);

        if (orec) {
                sdp_record_t *nrec = extract_pdu_server(BDADDR_ANY, p, 
bufsize,
                                                        handle, &scanned);
                if (nrec && handle == nrec->handle) {
                        update_db_timestamp();
                        update_svclass_list(BDADDR_ANY);
                } else {
                        SDPDBG("SvcRecHandle : 0x%x", handle);
                        SDPDBG("SvcRecHandleNew : 0x%x", nrec->handle);
                        SDPDBG("SvcRecNew : %p", nrec);
                        SDPDBG("SvcRecOld : %p", orec);
                        SDPDBG("Failure to update, restore old value");

                        status = SDP_INVALID_SYNTAX;
                }

                if (nrec)
                        sdp_record_free(nrec);
        } else
                status = SDP_INVALID_RECORD_HANDLE;

        p = rsp->data;
        bt_put_unaligned(htons(status), (uint16_t *) p);
        rsp->data_size = sizeof(uint16_t);
        return status;
}

If I comment the "sdp_record_free(nrec)" line, no segfault occurs.
If "extract_pdu_server" works like I think, first find the record, later 
delete all attrs and add the new attrs.
So that, sdp_record_free(nrec) is freeing the updated record, no?

I'm not in list, pleases cc'me.

Thanks and regards





^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: sdp update record
  2009-07-20  8:46 sdp update record josem
@ 2009-07-21 18:02 ` Luiz Augusto von Dentz
  0 siblings, 0 replies; 2+ messages in thread
From: Luiz Augusto von Dentz @ 2009-07-21 18:02 UTC (permalink / raw)
  To: josem; +Cc: linux-bluetooth

Hi,

On Mon, Jul 20, 2009 at 5:46 AM,
josem@robleshermoso.com<josem@robleshermoso.com> wrote:
> Hi everyone
>
> Working with BlueZ 4.46, bluetoothd process makes an segfault when an
> "update sdp record" request is processed. Running with valgrind memcheck
> I checked that when an "search attr" request arrives after the "update sdp
> record",
>  this record handle not exists because this memory has been freed in the
> "update sdp record" stage. The code block when "update spd record" is made
>

Thanks for reporting this, a patch has been pushed upstream to solve this:

http://git.kernel.org/?p=bluetooth/bluez.git;a=commitdiff;h=8c677a559dbaa7c9b53fea05f91081c05244ec1f

Note that nrec should reuse the memory from orec thus the assert.

-- 
Luiz Augusto von Dentz
Engenheiro de Computação

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-07-21 18:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-20  8:46 sdp update record josem
2009-07-21 18:02 ` Luiz Augusto von Dentz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox