linux-cve-announce - CVE-2025-68795: ethtool: Avoid overflowing userspace buffer on stats query

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2026011306-CVE-2025-68795-4e3e@gregkh>
Date: Tue, 13 Jan 2026 16:29:21 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2025-68795: ethtool: Avoid overflowing userspace buffer on stats query

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the 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 the size, ETHTOOL_GSTRINGS for the names, and
ETHTOOL_GSTATS for the values.

If the number of stats changes between these calls (e.g., due to device
reconfiguration), userspace's buffer allocation will be incorrect,
potentially leading to buffer overflow.

Drivers are generally expected to maintain stable stat counts, but some
drivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making
this scenario possible.

Some drivers try to handle this internally:
- bnad_get_ethtool_stats() returns early in case stats.n_stats is not
  equal to the driver's stats count.
- micrel/ksz884x also makes sure not to write anything beyond
  stats.n_stats and overflow the buffer.

However, both use stats.n_stats which is already assigned with the value
returned from get_sset_count(), hence won't solve the issue described
here.

Change ethtool_get_strings(), ethtool_get_stats(),
ethtool_get_phy_stats() to not return anything in case of a mismatch
between userspace's size and get_sset_size(), to prevent buffer
overflow.
The returned n_stats value will be equal to zero, to reflect that
nothing has been returned.

This could result in one of two cases when using upstream ethtool,
depending on when the size change is detected:
1. When detected in ethtool_get_strings():
    # ethtool -S eth2
    no stats available

2. When detected in get stats, all stats will be reported as zero.

Both cases are presumably transient, and a subsequent ethtool call
should succeed.

Other than the overflow avoidance, these two cases are very evident (no
output/cleared stats), which is arguably better than presenting
incorrect/shifted stats.
I also considered returning an error instead of a "silent" response, but
that seems more destructive towards userspace apps.

Notes:
- This patch does not claim to fix the inherent race, it only makes sure
  that we do not overflow the userspace buffer, and makes for a more
  predictable behavior.

- RTNL lock is held during each ioctl, the race window exists between
  the separate ioctl calls when the lock is released.

- Userspace ethtool always fills stats.n_stats, but it is likely that
  these stats ioctls are implemented in other userspace applications
  which might not fill it. The added code checks that it's not zero,
  to prevent any regressions.

The Linux kernel CVE team has assigned CVE-2025-68795 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.1.160 with commit 4afcb985355210e1688560dc47e64b94dad35d71
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.6.120 with commit ca9983bc3a1189bd72f9ae449d925a66b2616326
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.12.64 with commit 7bea09f60f2ad5d232e2db8f1c14e850fd3fd416
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.18.3 with commit 4066b5b546293f44cd6d0e84ece6e3ee7ff27093
	Issue introduced in 2.6.12 with commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 and fixed in 6.19-rc2 with commit 7b07be1ff1cb6c49869910518650e8d0abc7d25f

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-68795
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/ethtool/ioctl.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/4afcb985355210e1688560dc47e64b94dad35d71
	https://git.kernel.org/stable/c/ca9983bc3a1189bd72f9ae449d925a66b2616326
	https://git.kernel.org/stable/c/7bea09f60f2ad5d232e2db8f1c14e850fd3fd416
	https://git.kernel.org/stable/c/4066b5b546293f44cd6d0e84ece6e3ee7ff27093
	https://git.kernel.org/stable/c/7b07be1ff1cb6c49869910518650e8d0abc7d25f