Hi Syam, On Thu, Apr 12, 2012, Syam Sidhardhan wrote: > If we set the bluetooth name length as maximum 248 bytes, > then while retrieving back we were getting only 247 bytes. > This problem can be verified using hciconfig tool. > --- > lib/hci.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/lib/hci.c b/lib/hci.c > index 269c021..9f829c9 100644 > --- a/lib/hci.c > +++ b/lib/hci.c > @@ -1417,8 +1417,9 @@ int hci_read_local_name(int dd, int len, char *name, int to) > return -1; > } > > - rp.name[247] = '\0'; > - strncpy(name, (char *) rp.name, len); > + strncpy(name, (char *) rp.name, len - 1); > + name[len - 1] = '\0'; > + > return 0; > } This doesn't look quite right to me. What if the local name is not nul terminated (exactly 248 characters) and an application passes a buffer greater than 249 characters. It seems to me like you'd get a buffer over flow with the strncpy call in that case. Also, since this is a public library function we need to be very careful not to break the ABI. Some application might be "depending" on the brokeness of this function and break if we fix it. Since we're planning on making almost everything of libbluetooth private to BlueZ starting with 5.0 (I believe the socket structs and definitions may be the only exception) I'm not sure these two patches are worth it. Johan -- 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
