ixgbe: ethtool: stats user buffer overrun
authorJohn Fastabend <john.r.fastabend@intel.com>
Sat, 28 Jan 2012 03:32:17 +0000 (03:32 +0000)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Thu, 9 Feb 2012 09:27:47 +0000 (01:27 -0800)
commit9cc00b51a3cbb3b933065a55eaa9bfc306411b7a
tree5dc0dec3837ed23e0f2f0d070ebbf98d4243cdc0
parent5facb8e0c4dc1c8c47b71fd7f376defe16185733
ixgbe: ethtool: stats user buffer overrun

If the number of tx/rx queues changes the ethtool ioctl
ETHTOOL_GSTATS may overrun the userspace buffer. This
occurs because the general practice in user space to
query stats is to issue a ETHTOOL_GSSET cmd to learn the
buffer size needed, allocate the buffer, then call
ETHTOOL_GSTIRNGS and ETHTOOL_GSTATS. If the number of
real_num_queues is changed or flow control attributes
are changed after ETHTOOL_GSSET but before the
ETHTOOL_GSTRINGS/ETHTOOL_GSTATS a user space buffer
overrun occurs.

To fix the overrun always return the max buffer size
needed from get_sset_count() then return all strings
and stats from get_strings()/get_ethtool_stats().

This _will_ change the output from the ioctl() call
which could break applications and script parsing in
theory. I believe these changes should not break existing
tools because the only changes will be more {tx|rx}_queues
and the {tx|rx}_pb_* stats will always be returned.
Existing scripts already need to handle changing number
of queues because this occurs today depending on system
and current features. The {tx|rx}_pb_* stats are at the
end of the output and should be handled by scripts today
regardless.

Finally get_ethtool_stats and get_strings are free-form
outputs tools parsing these outputs should be defensive
anyways. In the end these updates are better then
having a tool segfault because of a buffer overrun.

Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c