Re: [PATCH net] rtnetlink: truncate IFLA_VFINFO_LIST instead of overflowing its length

[Jacob Keller]

On 7/29/2026 6:55 PM, Jakub Kicinski wrote:
> On Sat, 25 Jul 2026 16:22:36 +0300 Artem Lytkin wrote:
>> rtnl_fill_vf() closes the IFLA_VFINFO_LIST nest with nla_nest_end(),
>> which stores the accumulated length into nla_len. That field is a u16,
>> so a nest larger than 65535 bytes is written truncated modulo 65536.
>>
>> The skb is sized by if_nlmsg_size(), which adds rtnl_vfinfo_size() for
>> every VF, so the buffer really is large enough for the whole list and
>> none of the nla_put() calls in rtnl_fill_vfinfo() fails. The overflow is
>> therefore silent. Userspace then walks the message with RTA_NEXT(),
>> which advances by the stored length, so parsing resumes inside VF
>> payload and the top-level attributes that follow the nest are read out
>> of VF data. Those are IFLA_VF_PORTS, IFLA_XDP, IFLA_LINKINFO,
>> IFLA_PERM_ADDRESS and IFLA_PROP_LIST. iproute2 prints "!!!Deficit", and
>> strictly validating parsers reject the message outright.
>>
>> rtnl_fill_vfinfo() emits 296 bytes per VF on a 64-bit kernel with
>> efficient unaligned access, so the nest wraps at 222 VFs; without
>> CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS it is 328 bytes and 200 VFs, and
>> with ndo_get_vf_guid 336 bytes and 196 VFs. ice supports up to 256 VFs
>> per PF (ICE_MAX_SRIOV_VFS), so this is reachable on shipping hardware.
>> Requests that set RTEXT_FILTER_SKIP_STATS need 335 VFs, which the 256-VF
>> limit puts out of reach, so plain "ip link show" is fine today while
>> "ip -s link show" is not.
> 
> We should cap the output at known values and document them as the max
> the interface supports. "The number depends on attr set and random
> things like CPU alignment requirements" sounds like a terrible uAPI
> contract.
> 
> Perhaps 128 with stats and 256 without?
> 

This seems reasonable to me.

>> On CONFIG_DEBUG_NET kernels nla_nest_end() now also splats via
>> DEBUG_NET_WARN_ON_ONCE(), added along with nla_nest_end_safe() in commit
>> 1346586a9ac9 ("netlink: add a nla_nest_end_safe() helper").
>>
>> Using nla_nest_end_safe() here would not help: a nest that does not fit
>> in a u16 will not fit in a retried skb either, so returning -EMSGSIZE
>> would turn "ip link show" on such a device into a hard failure. Bound
>> the nest in the writer instead, as suggested when this was last
>> discussed: drop the VF that would push it past U16_MAX and end the list
>> there. Userspace sees IFLA_NUM_VF unchanged and a shorter
>> IFLA_VFINFO_LIST, and everything after the nest stays parsable. An empty
>> nest is already emitted for a PF with no VFs, so a list shorter than
>> IFLA_NUM_VF is not a new encoding.
>>
>> The other large nests in rtnl_fill_ifinfo() were audited and cannot
>> overflow: IFLA_AF_SPEC is bounded by a handful of address families at
>> about a kilobyte each, and IFLA_VF_PORTS would need more than 560 VFs.
>>
>> Fixes: c02db8c6290b ("rtnetlink: make SR-IOV VF interface symmetric")
> 
> Not a fix - this is along standing limitation of the interface.

I'd argue this is a "fix", as we were previously doing objectively the
wrong thing by randomly truncating the message at arbitrary points.

That being said, this *is* a well known limitation of the interface that
has been around for a while, so I can accept the argument not to tag it
as a fix for net.