-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Saturday, 23 May 2026 2:13
To: davem@davemloft.net
Cc: netdev@vger.kernel.org; edumazet@google.com; pabeni@redhat.com;
andrew+netdev@lunn.ch; horms@kernel.org;
maxime.chevallier@bootlin.com; Danielle Ratson [off-list ref];
Petr Machata [off-list ref]; o.rempel@pengutronix.de; Ido Schimmel
[off-list ref]; Jakub Kicinski [off-list ref]; andrew@lunn.ch;
kees@kernel.org
Subject: [PATCH net 6/9] ethtool: cmis: require exact CDB reply length

Malicious SFP module could respond with rpl_len longer than what
cmis_cdb_process_reply() expected, leading to OOB writes.
Malicious HW is a bit theoretical but some modules may just be buggy and/or
the reads may occasionally get corrupted, so let's protect the kernel.

The existing check protects from short replies. We need to protect from long
ones, too. All callers that pass a non-zero rpl_exp_len cast the reply payload to
a fixed-layout struct and read fields at fixed offsets, with no version
negotiation or short-reply handling:

  - cmis_cdb_validate_password()
  - cmis_cdb_module_features_get()
  - cmis_fw_update_fw_mng_features_get()

so let's assume that responses longer than expected do not have to be
handled gracefully here. Add a warning message to make the debug easier in
case my understanding is wrong...

Note that page_data->length (argument of kmalloc) comes from last arg to
ethtool_cmis_page_init() which is rpl_exp_len.

Note2 that AIs also like to point out overflows in args->req.payload itself
(which is a fixed-size 120 B buffer, on the stack), but callers should be reading
structs defined by the standard, so protecting from requests for more data
than max seem like defensive programming.

Fixes: a39c84d79625 ("ethtool: cmis_cdb: Add a layer for supporting CDB
commands")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: andrew@lunn.ch
CC: kees@kernel.org
CC: danieller@nvidia.com
CC: petrm@nvidia.com
---

Reviewed-by: Danielle Ratson <redacted>