Kernel fixes ethtool ntuple dumps that overflowed heap for any user

Jakub Kicinski has posted fixes for three Linux network drivers whose ethtool RX classification dumps could overflow the kernel heap, or hit a null pointer, in the hands of an ordinary user.

The ETHTOOL_GRXCLSRLALL path needs no CAP_NET_ADMIN. Userspace picks the buffer size through rule_cnt, and the ioctl allocates from that figure. Once an administrator has installed ntuple or policy rules, any process can request fewer slots than exist. The Broadcom SF2 DSA CFP code, Netronome NFP flow steering, and Marvell mv88e6xxx policy dump all walked their full tables into rule_locs without consulting that limit, writing past the allocation. A rule_cnt of zero left a null buffer pointer that the same walks dereferenced.

Kicinski built a proof of concept by planting the same mistake in another driver under QEMU after scanning for the pattern. The NFP change was reported by VEGA. A second NFP fix drops a replaced software entry when hardware reprogramming fails, so the advertised rule count cannot drift below the list the dump walks and leave a permanent short buffer.

The drivers now stop with EMSGSIZE when the caller buffer fills, matching other ntuple implementations, and report how many locations they actually wrote. Kernel ethtool documentation now states explicitly that rule_cnt is a user-provided ceiling, that rule_locs may be null when it is zero, and that drivers must treat an undersized request as an error rather than a full-table dump.

Broadcom maintainers noted they had been about to send the same SF2 bound internally. A separate mv88e6xxx concern, that rules may be readable or deletable from the wrong port, is left for net-next if the current behavior is confirmed unintentional.