Re: hci_sock.c build failure

[Marcel Holtmann <marcel@holtmann.org>]

Hi Toralf,

> I'm wondering why the build failure wasn't fixed by a patch like this:
> 
> 
> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> index 5ccea5f..85416bb 100644
> --- a/net/bluetooth/hci_sock.c
> +++ b/net/bluetooth/hci_sock.c
> @@ -348,8 +348,6 @@ static inline void hci_sock_cmsg(struct sock *sk, struct msghdr *msg, struct sk_
> 
>                 skb_get_timestamp(skb, &tv);
> 
> -               data = &tv;
> -               len = sizeof(tv);
>  #ifdef CONFIG_COMPAT
>                 if (msg->msg_flags & MSG_CMSG_COMPAT) {
>                         struct compat_timeval ctv;
> @@ -358,6 +356,9 @@ static inline void hci_sock_cmsg(struct sock *sk, struct msghdr *msg, struct sk_
>                         data = &ctv;
>                         len = sizeof(ctv);
>                 }
> +#else
> +               data = &tv;
> +               len = sizeof(tv);
>  #endif
> 
>                 put_cmsg(msg, SOL_HCI, HCI_CMSG_TSTAMP, len, data);

because that is wrong and will give you a different issue (the other way
around actually) that the change to use compat_timeval actually tried to
fix. Your patch actually will allow to return arbitrary kernel memory in
case of 64-bit applications since data and len might not be initialized.

In case of 64-bit kernels you can have 64-bit or 32-bit applications. In
case of 32-bit application you have to return compat_timeval and in cas
of 64-bit application you have to return timeval. It is checked by
MSG_CMSG_COMPAT runtime flag and not the CONFIG_COMPAT compile option.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/