diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2017-07-27 16:47:08 +0200 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2017-08-01 17:27:33 +0200 |
commit | 393c13b940be8f2e5b126cd9f442c12e7ecb4cac (patch) | |
tree | b6f47328533360c9c40e327e1fb17f53b7fc581c /blockdev.c | |
parent | f5aa69bdc3418773f26747ca282c291519626ece (diff) |
bt: stop the sdp memory allocation craziness
Clang static analyzer reports a memory leak. Actually, the allocated
memory escapes here:
record->attribute_list[record->attributes].pair = data;
but clang is correct that the memory might leak if len is zero. We
know it isn't; assert that it is the case.
The craziness doesn't end there. The memory is freed by
bt_l2cap_sdp_close_ch:
g_free(sdp->service_list[i].attribute_list->pair);
which actually should have been written like this:
g_free(sdp->service_list[i].attribute_list[0].pair);
The attribute_list is sorted with qsort; but indeed the first
entry of attribute_list should point to "data" even after the qsort,
because the first record has id SDP_ATTR_RECORD_HANDLE, whose
numeric value is zero.
But hang on. The qsort function is
static int sdp_attributeid_compare(
const struct sdp_service_attribute_s *a,
const struct sdp_service_attribute_s *b)
{
return (int) b->attribute_id - a->attribute_id;
}
but no one ever writes attribute_id. So it only works if qsort is
stable, and who knows what else is broken, but we can fix it by
setting attribute_id in the while loop.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'blockdev.c')
0 files changed, 0 insertions, 0 deletions