In the Linux kernel, following vulnerability has been resolved: ethtool: Avoid overflowing userspace buffer on stats query The ethtool -S command operates across three ioctl calls: ETHTOOL_GSSET_INFO for size, ETHTOOL_GSTRINGS names, and ETHTOOL_GSTATS values. If number of changes between these calls (e.g., due to device reconfiguration), userspace's allocation will be incorrect, potentially leading overflow. Drivers are generally expected maintain stable stat counts, but some drivers mlx5, bnx2x, bna, ksz884x) use dynamic counters, making this scenario possible. Some drivers try handle this internally: - bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal driver's count. - micrel/ksz884x also makes sure not write anything beyond and overflow buffer. However, both which already assigned with value returned from get_sset_count(), hence won't solve issue described here. Change ethtool_get_strings(), ethtool_get_stats(), ethtool_get_phy_stats() return a mismatch between size get_sset_size(), prevent buffer overflow. The returned n_stats value zero, reflect that nothing returned. This could result one two cases when using upstream ethtool, depending change detected: 1. When detected ethtool_get_strings(): # eth2 no available 2. get stats, all reported as zero. Both presumably transient, subsequent call should succeed. Other than avoidance, very evident (no output/cleared stats), arguably better presenting incorrect/shifted stats. I considered returning an error instead "silent" response, but that seems more destructive towards apps. Notes: - This patch does claim fix inherent race, it only sure that we do buffer, more predictable behavior. - RTNL lock held during each ioctl, race window exists between separate released. - Userspace always fills stats.n_stats, likely that ioctls implemented other applications might fill it. The added code checks it's zero, any regressions.