CVE-2025-68795

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