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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
