[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1dc163b0-d4b0-8f6c-d047-7eae6dc918c4@gmail.com>
Date: Sat, 23 Jan 2021 12:14:17 -0700
From: David Ahern <dsahern@...il.com>
To: Edwin Peer <edwin.peer@...adcom.com>, netdev@...r.kernel.org
Cc: Jakub Kicinski <kuba@...nel.org>,
Andrew Gospodarek <andrew.gospodarek@...adcom.com>,
Michael Chan <michael.chan@...adcom.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Michal Kubecek <mkubecek@...e.cz>
Subject: Re: [PATCH net-next 1/4] netlink: truncate overlength attribute list
in nla_nest_end()
On 1/22/21 9:53 PM, Edwin Peer wrote:
> If a nested list of attributes is too long, then the length will
> exceed the 16-bit nla_len of the parent nlattr. In such cases,
> determine how many whole attributes can fit and truncate the
> message to this length. This properly maintains the nesting
> hierarchy, keeping the entire message valid, while fitting more
> subelements inside the nest range than may result if the length
> is wrapped modulo 64KB.
>
> Marking truncated attributes, such that user space can determine
> the precise attribute truncated, by means of an additional bit in
> the nla_type was considered and rejected. The NLA_F_NESTED and
> NLA_F_NET_BYTEORDER flags are supposed to be mutually exclusive.
> So, in theory, the latter bit could have been redefined for nested
> attributes in order to indicate truncation, but user space tools
> (most notably iproute2) cannot be relied on to honor NLA_TYPE_MASK,
> resulting in alteration of the perceived nla_type and subsequent
> catastrophic failure.
>
Did you look at using NETLINK_CB / netlink_skb_parms to keep a running
length of nested attributes to avoid the need to trim?
Powered by blists - more mailing lists