[<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
Powered by blists - more mailing lists