CVE-2025-68795
Severity CVSS v4.0:
Pending analysis
Type:
Unavailable / Other
Publication date:
13/01/2026
Last modified:
13/01/2026
Description
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&#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&#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&#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&#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&#39;s not zero,<br />
to prevent any regressions.
Impact
References to Advisories, Solutions, and Tools
- https://git.kernel.org/stable/c/4066b5b546293f44cd6d0e84ece6e3ee7ff27093
- https://git.kernel.org/stable/c/4afcb985355210e1688560dc47e64b94dad35d71
- https://git.kernel.org/stable/c/7b07be1ff1cb6c49869910518650e8d0abc7d25f
- https://git.kernel.org/stable/c/7bea09f60f2ad5d232e2db8f1c14e850fd3fd416
- https://git.kernel.org/stable/c/ca9983bc3a1189bd72f9ae449d925a66b2616326



