ethtool: document that GRXCLSRLALL rule_cnt is a caller-provided limit

Three drivers have shipped a get_rxnfc() which dumps its entire rule
table into rule_locs, reading rule_cnt as "how many rules do I have"
rather than "how many entries did the caller allocate".  Nothing in the
callback's documentation contradicted that reading.  The distinction only
matters because the ioctl lets an unprivileged caller pick rule_cnt
directly, so getting it wrong is a heap overflow rather than a truncated
dump.

Reviewed-by: Joe Damato <joe@dama.to>
Link: https://patch.msgid.link/20260903032611.3000029-6-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This commit is contained in:
Jakub Kicinski 2026-09-02 20:26:11 -07:00
parent b1fffc2731
commit 47a582b2b0

View File

@ -1057,6 +1057,12 @@ struct kernel_ethtool_ts_info {
* @get_sset_count: Get number of strings that @get_strings will write.
* @get_rxnfc: Get RX flow classification rules. Returns a negative
* error code or zero.
* Note that for %ETHTOOL_GRXCLSRLALL rule_cnt and size of the arrays
* is user-provided, and not guaranteed to match what driver would
* have reported via %ETHTOOL_GRXCLSRLCNT. Drivers must return -%EMSGSIZE
* when rule_cnt is too small. rule_locs is %NULL when rule_cnt is zero.
* On success drivers must set rule_cnt to the number of locations they
* filled in, the core copies out exactly that many.
* @set_rxnfc: Set RX flow classification rules. Returns a negative
* error code or zero.
* @flash_device: Write a firmware image to device's flash memory.