FKIE_CVE-2025-68795

Vulnerability from fkie_nvd - Published: 2026-01-13 16:16 - Updated: 2026-04-15 00:35
Severity ?
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/3df375a1e75483b7d973c3cc2e46aa374db8428b
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4066b5b546293f44cd6d0e84ece6e3ee7ff27093
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/4afcb985355210e1688560dc47e64b94dad35d71
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7b07be1ff1cb6c49869910518650e8d0abc7d25f
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7bea09f60f2ad5d232e2db8f1c14e850fd3fd416
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ca9983bc3a1189bd72f9ae449d925a66b2616326
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/f9dc0f45d2cd0189ce666288a29d2cc32c2e44d5
Impacted products
Vendor Product Version
To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: Avoid overflowing userspace buffer on stats query\n\nThe ethtool -S command operates across three ioctl calls:\nETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and\nETHTOOL_GSTATS for the values.\n\nIf the number of stats changes between these calls (e.g., due to device\nreconfiguration), userspace\u0027s buffer allocation will be incorrect,\npotentially leading to buffer overflow.\n\nDrivers are generally expected to maintain stable stat counts, but some\ndrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making\nthis scenario possible.\n\nSome drivers try to handle this internally:\n- bnad_get_ethtool_stats() returns early in case stats.n_stats is not\n  equal to the driver\u0027s stats count.\n- micrel/ksz884x also makes sure not to write anything beyond\n  stats.n_stats and overflow the buffer.\n\nHowever, both use stats.n_stats which is already assigned with the value\nreturned from get_sset_count(), hence won\u0027t solve the issue described\nhere.\n\nChange ethtool_get_strings(), ethtool_get_stats(),\nethtool_get_phy_stats() to not return anything in case of a mismatch\nbetween userspace\u0027s size and get_sset_size(), to prevent buffer\noverflow.\nThe returned n_stats value will be equal to zero, to reflect that\nnothing has been returned.\n\nThis could result in one of two cases when using upstream ethtool,\ndepending on when the size change is detected:\n1. When detected in ethtool_get_strings():\n    # ethtool -S eth2\n    no stats available\n\n2. When detected in get stats, all stats will be reported as zero.\n\nBoth cases are presumably transient, and a subsequent ethtool call\nshould succeed.\n\nOther than the overflow avoidance, these two cases are very evident (no\noutput/cleared stats), which is arguably better than presenting\nincorrect/shifted stats.\nI also considered returning an error instead of a \"silent\" response, but\nthat seems more destructive towards userspace apps.\n\nNotes:\n- This patch does not claim to fix the inherent race, it only makes sure\n  that we do not overflow the userspace buffer, and makes for a more\n  predictable behavior.\n\n- RTNL lock is held during each ioctl, the race window exists between\n  the separate ioctl calls when the lock is released.\n\n- Userspace ethtool always fills stats.n_stats, but it is likely that\n  these stats ioctls are implemented in other userspace applications\n  which might not fill it. The added code checks that it\u0027s not zero,\n  to prevent any regressions."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nethtool: Evitar el desbordamiento del b\u00fafer del espacio de usuario en la consulta de estad\u00edsticas\n\nEl comando ethtool -S opera a trav\u00e9s de tres llamadas ioctl:\nETHTOOL_GSSET_INFO para el tama\u00f1o, ETHTOOL_GSTRINGS para los nombres, y\nETHTOOL_GSTATS para los valores.\n\nSi el n\u00famero de estad\u00edsticas cambia entre estas llamadas (p. ej., debido a la\nreconfiguraci\u00f3n del dispositivo), la asignaci\u00f3n de b\u00fafer del espacio de usuario ser\u00e1 incorrecta,\nlo que podr\u00eda llevar a un desbordamiento de b\u00fafer.\n\nGeneralmente se espera que los controladores mantengan recuentos de estad\u00edsticas estables, pero algunos\ncontroladores (p. ej., mlx5, bnx2x, bna, ksz884x) usan contadores din\u00e1micos, haciendo\nposible este escenario.\n\nAlgunos controladores intentan manejar esto internamente:\n- bnad_get_ethtool_stats() retorna temprano en caso de que stats.n_stats no sea\n  igual al recuento de estad\u00edsticas del controlador.\n- micrel/ksz884x tambi\u00e9n se asegura de no escribir nada m\u00e1s all\u00e1 de\n  stats.n_stats y desbordar el b\u00fafer.\n\nSin embargo, ambos usan stats.n_stats que ya est\u00e1 asignado con el valor\nretornado de get_sset_count(), por lo tanto, no resolver\u00e1 el problema descrito\naqu\u00ed.\n\nCambiar ethtool_get_strings(), ethtool_get_stats(),\nethtool_get_phy_stats() para no retornar nada en caso de una discrepancia\nentre el tama\u00f1o del espacio de usuario y get_sset_size(), para prevenir el desbordamiento de b\u00fafer.\nEl valor n_stats retornado ser\u00e1 igual a cero, para reflejar que\nno se ha retornado nada.\n\nEsto podr\u00eda resultar en uno de dos casos al usar ethtool upstream,\ndependiendo de cu\u00e1ndo se detecte el cambio de tama\u00f1o:\n1. Cuando se detecta en ethtool_get_strings():\n    # ethtool -S eth2\n    no hay estad\u00edsticas disponibles\n\n2. Cuando se detecta en la obtenci\u00f3n de estad\u00edsticas, todas las estad\u00edsticas se reportar\u00e1n como cero.\n\nAmbos casos son presumiblemente transitorios, y una llamada ethtool subsiguiente\ndeber\u00eda tener \u00e9xito.\n\nAparte de la evitaci\u00f3n del desbordamiento, estos dos casos son muy evidentes (sin\nsalida/estad\u00edsticas borradas), lo cual es posiblemente mejor que presentar\nestad\u00edsticas incorrectas/desplazadas.\nTambi\u00e9n consider\u00e9 retornar un error en lugar de una respuesta \u0027silenciosa\u0027, pero\neso parece m\u00e1s destructivo para las aplicaciones del espacio de usuario.\n\nNotas:\n- Este parche no pretende corregir la condici\u00f3n de carrera inherente, solo se asegura\n  de que no desbordemos el b\u00fafer del espacio de usuario, y proporciona un comportamiento\n  m\u00e1s predecible.\n\n- El bloqueo RTNL se mantiene durante cada ioctl, la ventana de carrera existe entre\n  las llamadas ioctl separadas cuando se libera el bloqueo.\n\n- ethtool del espacio de usuario siempre llena stats.n_stats, pero es probable que\n  estas ioctls de estad\u00edsticas est\u00e9n implementadas en otras aplicaciones del espacio de usuario\n  que podr\u00edan no llenarlo. El c\u00f3digo a\u00f1adido verifica que no sea cero,\n  para prevenir cualquier regresi\u00f3n."
    }
  ],
  "id": "CVE-2025-68795",
  "lastModified": "2026-04-15T00:35:42.020",
  "metrics": {},
  "published": "2026-01-13T16:16:01.420",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/3df375a1e75483b7d973c3cc2e46aa374db8428b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4066b5b546293f44cd6d0e84ece6e3ee7ff27093"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/4afcb985355210e1688560dc47e64b94dad35d71"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7b07be1ff1cb6c49869910518650e8d0abc7d25f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7bea09f60f2ad5d232e2db8f1c14e850fd3fd416"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ca9983bc3a1189bd72f9ae449d925a66b2616326"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f9dc0f45d2cd0189ce666288a29d2cc32c2e44d5"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Deferred"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.