linux-hardening - Re: [PATCH net-next v2] netlink: split up copies in the ack construction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e97660d-32ff-c0cc-951b-5beda6283571@embeddedor.com>
Date:   Wed, 16 Nov 2022 18:55:36 -0600
From:   "Gustavo A. R. Silva" <gustavo@...eddedor.com>
To:     Kees Cook <keescook@...omium.org>, Jakub Kicinski <kuba@...nel.org>
Cc:     David Ahern <dsahern@...nel.org>, davem@...emloft.net,
        netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH net-next v2] netlink: split up copies in the ack
 construction



On 11/16/22 18:27, Kees Cook wrote:
> On Wed, Nov 16, 2022 at 02:56:25PM -0800, Kees Cook wrote:
>> On Mon, Nov 14, 2022 at 09:06:14AM -0800, Jakub Kicinski wrote:
>>> On Sun, 13 Nov 2022 19:39:27 -0700 David Ahern wrote:
>>>> On Thu, Oct 27, 2022 at 02:25:53PM -0700, Jakub Kicinski wrote:
>>>>> diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
>>>>> index e2ae82e3f9f7..5da0da59bf01 100644
>>>>> --- a/include/uapi/linux/netlink.h
>>>>> +++ b/include/uapi/linux/netlink.h
>>>>> @@ -48,6 +48,7 @@ struct sockaddr_nl {
>>>>>    * @nlmsg_flags: Additional flags
>>>>>    * @nlmsg_seq:   Sequence number
>>>>>    * @nlmsg_pid:   Sending process port ID
>>>>> + * @nlmsg_data:  Message payload
>>>>>    */
>>>>>   struct nlmsghdr {
>>>>>   	__u32		nlmsg_len;
>>>>> @@ -55,6 +56,7 @@ struct nlmsghdr {
>>>>>   	__u16		nlmsg_flags;
>>>>>   	__u32		nlmsg_seq;
>>>>>   	__u32		nlmsg_pid;
>>>>> +	__u8		nlmsg_data[];
>>>>
>>>> This breaks compile of iproute2 with clang. It does not like the
>>>> variable length array in the middle of a struct. While I could re-do the
>>>> structs in iproute2, I doubt it is alone in being affected by this
>>>> change.

Yep; this is a fine Clang warning. We cannot have a variable length object
immediately followed by another object because that would cause undefined
behavior.

>>
>> Eww.
>>
>>>
>>> Kees, would you mind lending your expertise?
> 
> Perhaps this would be better? We could leave the _header_ struct alone,
> but add the data to the nlmsgerr struct instead?
> 
> diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
> index 5da0da59bf01..d0629cb343b2 100644
> --- a/include/uapi/linux/netlink.h
> +++ b/include/uapi/linux/netlink.h
> @@ -48,7 +48,6 @@ struct sockaddr_nl {
>    * @nlmsg_flags: Additional flags
>    * @nlmsg_seq:   Sequence number
>    * @nlmsg_pid:   Sending process port ID
> - * @nlmsg_data:  Message payload
>    */
>   struct nlmsghdr {
>   	__u32		nlmsg_len;
> @@ -56,7 +55,6 @@ struct nlmsghdr {
>   	__u16		nlmsg_flags;
>   	__u32		nlmsg_seq;
>   	__u32		nlmsg_pid;
> -	__u8		nlmsg_data[];
>   };

This seems to be a sensible change. In general, it's not a good idea
to have variable length objects (flex-array members) in structures used
as headers, and that we know will ultimately be followed by more objects
when embedded inside other structures.

>   
>   /* Flags values */
> @@ -121,6 +119,7 @@ struct nlmsghdr {
>   struct nlmsgerr {
>   	int		error;
>   	struct nlmsghdr msg;
> +	__u8		data[];
>   	/*
>   	 * followed by the message contents unless NETLINK_CAP_ACK was set
>   	 * or the ACK indicates success (error == 0)
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index b8afec32cff6..fe8493d3ae56 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -2514,8 +2514,7 @@ void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err,
>   		if (!nlmsg_append(skb, nlmsg_len(nlh)))
>   			goto err_bad_put;
>   
> -		memcpy(errmsg->msg.nlmsg_data, nlh->nlmsg_data,
> -		       nlmsg_len(nlh));
> +		memcpy(errmsg->data, nlmsg_data(nlh), nlmsg_len(nlh));
>   	}
>   
>   	if (tlvlen)
> 
> 

--
Gustavo