Hi Chanyeol, >>>>> addr can be NULL and it should not be dereferenced before NULL >>>>> checking. >>>>> >>>>> Signed-off-by: Jaganath Kanakkassery <jaganath.k@xxxxxxxxxxx> >>>>> --- >>>> >>>> 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. > Could you tell us why this is good idea? I failed to find it in git > history/mailing list. > > In addition to RFCOMM connect that you mentioned, I found out SCO > connect/bind still use the old style in Bluetooth unlikely HCI,L2CAP. it avoids any kind of leakage and allows for an easy extension of the socket data structures if we ever have to. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
