Re: Re: [PATCH] Bluetooth: Fix potential NULL dereference

Re: Re: [PATCH] Bluetooth: Fix potential NULL dereference

[JAGANATH KANAKKASSERY]

SGkgTWFyY2VsLA0KDQo+PiBhZGRyIGNhbiBiZSBOVUxMIGFuZCBpdCBzaG91bGQgbm90IGJlIGRl
cmVmZXJlbmNlZCBiZWZvcmUgTlVMTCBjaGVja2luZy4NCj4+IA0KPj4gU2lnbmVkLW9mZi1ieTog
SmFnYW5hdGggS2FuYWtrYXNzZXJ5IDxqYWdhbmF0aC5rQHNhbXN1bmcuY29tPg0KPj4gLS0tDQo+
DQo+aWYgd2Ugc3RhcnQgY2hhbmdpbmcgdGhpbmdzIGhlcmUsIHRoZW4gd2UgYmV0dGVyIGNoYW5n
ZSB0aGUgY29kZSBpbnRvIHNvbWV0aGluZyB0aGF0IGFsbCB0aGUgb3RoZXIgc29ja2V0IGhhbmRs
aW5nIGNvZGUgaXMgZG9pbmcgYW55d2F5PnkuIFNvIGRvIHRoZSBtaW4gY29tcGFyaXNvbiBhbmQg
Y29weSB0aGUgZGF0YSBpbnRvIGEgbG9jYWwgY29weSBvZiB0aGUgc29ja2FkZHJfcmMuDQo+DQo+
QW5kIG9uIGEgc2lkZSBub3RlLCBJIHdvbmRlciBpZiBhZGRyIGNhbiBhY3R1YWxseSBiZSBOVUxM
LiBJdCBtaWdodCBiZSBpbnRlcmVzdGluZyB0byBjaGVjayB0aGUgZ2VuZXJpYyBzb2NrZXQgY29k
ZSBpZiB0aGlzIHJlYWxseSBjYW4gaGFwcGU+biBpZiB5b3UgcHJvdmlkZSBubyBhZGRyZXNzIHN0
cnVjdHVyZSB0byB0aGUgYmluZCgpIHN5c3RlbSBjYWxsIG9yIGlmIHRoaXMgZ2V0cyBmaWx0ZXJl
ZCBvdXQgYnkgdGhlIGNvcmUgc29ja2V0IGNvZGUuDQoNCkkgY2hlY2tlZCBnZW5lcmljIHNvY2tl
dCBjb2RlIGFuZCBpdCBsb29rcyBsaWtlIGFkZHIgd2lsbCBuZXZlciBiZSBOVUxMIHdoZW4gdXNl
ciBzcGFjZSBjYWxscyBiaW5kLg0KQnV0IHRoaXMgY2FuIGJlIGNhbGxlZCBmcm9tIGtlcm5lbF9i
aW5kKCkgYWxzbyB3aGljaCBJIHRoaW5rIHdpbGwgbmV2ZXIgYmUgY2FsbGVkIGZvciBSRkNPTU0u
DQpTbyB0aGlzIHBhdGNoIGlzIG5vdCByZXF1aXJlZD8gDQoNClRoYW5rcywNCkphZ2FuYXRo

Re: Re: [PATCH] Bluetooth: Fix potential NULL dereference

[JAGANATH KANAKKASSERY]

SGkgTWFyY2VsLA0KDQo+Pj4+IGFkZHIgY2FuIGJlIE5VTEwgYW5kIGl0IHNob3VsZCBub3QgYmUg
ZGVyZWZlcmVuY2VkIGJlZm9yZSBOVUxMIGNoZWNraW5nLg0KPj4+PiANCj4+Pj4gU2lnbmVkLW9m
Zi1ieTogSmFnYW5hdGggS2FuYWtrYXNzZXJ5IDxqYWdhbmF0aC5rQHNhbXN1bmcuY29tPg0KPj4+
PiAtLS0NCj4+ID4NCj4+ID5pZiB3ZSBzdGFydCBjaGFuZ2luZyB0aGluZ3MgaGVyZSwgdGhlbiB3
ZSBiZXR0ZXIgY2hhbmdlIHRoZSBjb2RlIGludG8gc29tZXRoaW5nIHRoYXQgYWxsIHRoZSBvdGhl
ciBzb2NrZXQgaGFuZGxpbmcgY29kZSBpcyBkb2luZyBhbnl3YXk+eS4gU28gZG8gdGhlIG1pbiBj
b21wYXJpc29uIGFuZCBjb3B5IHRoZSBkYXRhIGludG8gYSBsb2NhbCBjb3B5IG9mIHRoZSBzb2Nr
YWRkcl9yYy4NCj4+Pg0KPj4+IEFuZCBvbiBhIHNpZGUgbm90ZSwgSSB3b25kZXIgaWYgYWRkciBj
YW4gYWN0dWFsbHkgYmUgTlVMTC4gSXQgbWlnaHQgYmUgaW50ZXJlc3RpbmcgdG8gY2hlY2sgdGhl
IGdlbmVyaWMgc29ja2V0IGNvZGUgaWYgdGhpcyByZWFsbHkgY2FuIGhhcHBlPm4gaWYgeW91IHBy
b3ZpZGUgbm8gYWRkcmVzcyBzdHJ1Y3R1cmUgdG8gdGhlIGJpbmQoKSBzeXN0ZW0gY2FsbCBvciBp
ZiB0aGlzIGdldHMgZmlsdGVyZWQgb3V0IGJ5IHRoZSBjb3JlIHNvY2tldCBjb2RlLg0KPj4gDQo+
PiBJIGNoZWNrZWQgZ2VuZXJpYyBzb2NrZXQgY29kZSBhbmQgaXQgbG9va3MgbGlrZSBhZGRyIHdp
bGwgbmV2ZXIgYmUgTlVMTCB3aGVuIHVzZXIgc3BhY2UgY2FsbHMgYmluZC4NCj4+IEJ1dCB0aGlz
IGNhbiBiZSBjYWxsZWQgZnJvbSBrZXJuZWxfYmluZCgpIGFsc28gd2hpY2ggSSB0aGluayB3aWxs
IG5ldmVyIGJlIGNhbGxlZCBmb3IgUkZDT01NLg0KPj4gU28gdGhpcyBwYXRjaCBpcyBub3QgcmVx
dWlyZWQ/IA0KPg0KPnRoYXQgaXMgd2hhdCBJIHRob3VnaHQuIEhvd2V2ZXIgY29udmVydGluZyBp
dCB0byB0aGUgc2FtZSBoYW5kbGluZyB1c2luZyBtaW4gYW5kIGNvcHlpbmcgaW50byBsb2NhbCBz
dG9yYWdlIG1pZ2h0IGJlIGEgZ29vZCBpZGVhLiBUaGUgbW9yZSBwaWVjZXMgaW4gSENJLCBMMkNB
UCwgU0NPIGFuZCBSRkNPTU0gc29ja2V0cyB0aGF0IGFyZSBzaW1pbGFyLCB0aGUgYmV0dGVyLg0K
DQpJIGhhdmUgcmFpc2VkIHYxIHdpdGggdGhlIGNoYW5nZXMgeW91IHN1Z2dlc3RlZCwgUGx6IGNo
ZWNrIGl0Lg0KDQpUaGFua3MsDQpKYWdhbmF0aA==

Re: Re: [PATCH] Bluetooth: Fix potential NULL dereference

[Jaganath K]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Ping.


On Fri, May 15, 2015 at 11:07 AM, JAGANATH KANAKKASSERY <
jaganath.k@samsung.com> wrote:

> Hi Marcel,
>
> >>>> addr can be NULL and it should not be dereferenced before NULL
> checking.
> >>>>
> >>>> Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
> >>>> ---
> >> >
> >> >if we start changing things here, then we better change the code into
> something that all the other socket handling code is doing anyway>y. So do
> the min comparison and copy the data into a local copy of the sockaddr_rc.
> >>>
> >>> And on a side note, I wonder if addr can actually be NULL. It might be
> interesting to check the generic socket code if this really can happe>n if
> you provide no address structure to the bind() system call or if this gets
> filtered out by the core socket code.
> >>
> >> I checked generic socket code and it looks like addr will never be NULL
> when user space calls bind.
> >> But this can be called from kernel_bind() also which I think will never
> be called for RFCOMM.
> >> So this patch is not required?
> >
> >that is what I thought. However converting it to the same handling using
> min and copying into local storage might be a good idea. The more pieces in
> HCI, L2CAP, SCO and RFCOMM sockets that are similar, the better.
>
> I have raised v1 with the changes you suggested, Plz check it.
>
> Thanks,
> Jaganath

[-- Attachment #2: Type: text/html, Size: 1928 bytes --]

Re: [PATCH] Bluetooth: Fix potential NULL dereference

[Marcel Holtmann]

Hi Jaganath,

> Ping.

so we agreed to not apply this patch. I might have missed your other patch. So just resend that one.

Regards

Marcel