From: Simon Horman <horms@kernel.org>
To: Danielle Ratson <danieller@nvidia.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, corbet@lwn.net,
linux@armlinux.org.uk, sdf@google.com, kory.maincent@bootlin.com,
maxime.chevallier@bootlin.com, vladimir.oltean@nxp.com,
przemyslaw.kitszel@intel.com, ahmed.zaki@intel.com,
richardcochran@gmail.com, shayagr@amazon.com,
paul.greenwalt@intel.com, jiri@resnulli.us,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
mlxsw@nvidia.com, petrm@nvidia.com, idosch@nvidia.com
Subject: Re: [RFC PATCH net-next 7/9] ethtool: cmis_cdb: Add a layer for supporting CDB commands
Date: Mon, 22 Jan 2024 10:31:00 +0000 [thread overview]
Message-ID: <20240122103100.GA126470@kernel.org> (raw)
In-Reply-To: <20240122084530.32451-8-danieller@nvidia.com>
On Mon, Jan 22, 2024 at 10:45:28AM +0200, Danielle Ratson wrote:
...
> +/**
> + * struct ethtool_cmis_cdb_request - CDB commands request fields as decribed in
> + * the CMIS standard
> + * @id: Command ID.
> + * @epl_len: EPL memory length.
> + * @lpl_len: LPL memory length.
> + * @chk_code: Check code for the previous field and the payload.
> + * @resv1: Added to match the CMIS standard request continuity.
> + * @resv2: Added to match the CMIS standard request continuity.
> + * @payload: Payload for the CDB commands.
> + */
> +struct ethtool_cmis_cdb_request {
> + __be16 id;
> + struct_group(body,
> + u16 epl_len;
> + u8 lpl_len;
> + u8 chk_code;
> + u8 resv1;
> + u8 resv2;
> + u8 payload[ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH];
> + );
> +};
> +
> +#define CDB_F_COMPLETION_VALID BIT(0)
> +#define CDB_F_STATUS_VALID BIT(1)
> +
> +/**
> + * struct ethtool_cmis_cdb_cmd_args - CDB commands execution arguments
> + * @req: CDB command fields as described in the CMIS standard.
> + * @max_duration: Maximum duration time for command completion in msec.
> + * @read_write_len_ext: Allowable additional number of byte octets to the LPL
> + * in a READ or a WRITE commands.
> + * @rpl_exp_len: Expected reply length in bytes.
> + * @flags: Validation flags for CDB commands.
> + */
> +struct ethtool_cmis_cdb_cmd_args {
> + struct ethtool_cmis_cdb_request req;
> + u16 max_duration;
> + u8 read_write_len_ext;
> + u8 rpl_exp_len;
> + u8 flags;
> +};
...
> +int ethtool_cmis_page_init(struct ethtool_module_eeprom *page_data,
> + u8 page, u32 offset, u32 length)
> +{
> + page_data->page = page;
> + page_data->offset = offset;
> + page_data->length = length;
> + page_data->i2c_address = ETHTOOL_CMIS_CDB_PAGE_I2C_ADDR;
> + page_data->data = kmalloc(page_data->length, GFP_KERNEL);
> + if (!page_data->data)
> + return -ENOMEM;
> +
> + return 0;
> +}
...
> +static int
> +__ethtool_cmis_cdb_execute_cmd(struct net_device *dev,
> + struct ethtool_module_eeprom *page_data,
> + u32 offset, u32 length, void *data)
> +{
> + const struct ethtool_ops *ops = dev->ethtool_ops;
> + struct netlink_ext_ack extack = {};
> + int err;
> +
> + page_data->offset = offset;
> + page_data->length = length;
> +
> + memset(page_data->data, 0, ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH);
> + memcpy(page_data->data, data, page_data->length);
> +
> + err = ops->set_module_eeprom_by_page(dev, page_data, &extack);
> + if (err < 0) {
> + if (extack._msg)
> + netdev_err(dev, "%s\n", extack._msg);
> + }
> +
> + return err;
> +}
...
> +int ethtool_cmis_cdb_execute_cmd(struct net_device *dev,
> + struct ethtool_cmis_cdb_cmd_args *args)
> +{
> + struct ethtool_module_eeprom page_data = {};
> + u32 offset;
> + int err;
> +
> + args->req.chk_code =
> + cmis_cdb_calc_checksum(&args->req, sizeof(args->req));
> +
> + if (args->req.lpl_len > args->read_write_len_ext) {
> + ethnl_module_fw_flash_ntf_err(dev,
> + "LPL length is longer than CDB read write length extension allows");
> + return -EINVAL;
> + }
> +
> + err = ethtool_cmis_page_init(&page_data, ETHTOOL_CMIS_CDB_CMD_PAGE, 0,
> + ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH);
ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH is passed as the length argument
of ethtool_cmis_page_init, which will allocate that many
bytes for page_data->data.
> + if (err < 0)
> + return err;
> +
> + /* According to the CMIS standard, there are two options to trigger the
> + * CDB commands. The default option is triggering the command by writing
> + * the CMDID bytes. Therefore, the command will be split to 2 calls:
> + * First, with everything except the CMDID field and then the CMDID
> + * field.
> + */
> + offset = CMIS_CDB_CMD_ID_OFFSET +
> + offsetof(struct ethtool_cmis_cdb_request, body);
> + err = __ethtool_cmis_cdb_execute_cmd(dev, &page_data, offset,
> + sizeof(args->req.body),
> + &args->req.body);
Hi Danielle,
However, here sizeof(args->req.body) is passed as the length
argument of __ethtool_cmis_cdb_execute_cmd() which will:
1. Zero ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH bytes of page_data->data
2. Copy sizeof(args->req.body) bytes into page_data->data
args->req.body includes several fields, one of which is
ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH bytes long. So,
args->req.body > ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH
and it seems that step 2 above causes a buffer overrun.
Flagged by clang-17 W=1 build
In file included from net/ethtool/cmis_cdb.c:3:
In file included from ./include/linux/ethtool.h:16:
In file included from ./include/linux/bitmap.h:12:
In file included from ./include/linux/string.h:295:
./include/linux/fortify-string.h:579:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
579 | __write_overflow_field(p_size_field, size);
| ^
./include/linux/fortify-string.h:579:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
./include/linux/fortify-string.h:579:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> + if (err < 0)
> + goto out;
> +
> + offset = CMIS_CDB_CMD_ID_OFFSET +
> + offsetof(struct ethtool_cmis_cdb_request, id);
> + err = __ethtool_cmis_cdb_execute_cmd(dev, &page_data, offset,
> + sizeof(args->req.id),
> + &args->req.id);
> + if (err < 0)
> + goto out;
> +
> + err = cmis_cdb_wait_for_completion(dev, args);
> + if (err < 0)
> + goto out;
> +
> + err = cmis_cdb_wait_for_status(dev, args);
> + if (err < 0)
> + goto out;
> +
> + err = cmis_cdb_process_reply(dev, &page_data, args);
> +
> +out:
> + ethtool_cmis_page_fini(&page_data);
> + return err;
> +}
...
next prev parent reply other threads:[~2024-01-22 10:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 8:45 [RFC PATCH net-next 0/9] Add ability to flash modules' firmware Danielle Ratson
2024-01-22 8:45 ` [RFC PATCH net-next 1/9] ethtool: Add ethtool operation to write to a transceiver module EEPROM Danielle Ratson
2024-01-23 17:03 ` Russell King (Oracle)
2024-01-24 13:10 ` Danielle Ratson
2024-01-25 20:26 ` Andrew Lunn
2024-01-25 20:45 ` Andrew Lunn
2024-01-30 7:43 ` Danielle Ratson
2024-01-31 11:51 ` Danielle Ratson
2024-01-22 8:45 ` [RFC PATCH net-next 2/9] mlxsw: Implement " Danielle Ratson
2024-01-22 8:45 ` [RFC PATCH net-next 3/9] ethtool: Add an interface for flashing transceiver modules' firmware Danielle Ratson
2024-01-23 1:37 ` Jakub Kicinski
2024-01-23 4:50 ` Jakub Kicinski
2024-01-23 13:34 ` Danielle Ratson
2024-01-23 15:53 ` Jakub Kicinski
2024-01-22 8:45 ` [RFC PATCH net-next 4/9] ethtool: Add flashing transceiver modules' firmware notifications ability Danielle Ratson
2024-01-22 8:45 ` [RFC PATCH net-next 5/9] include: netdevice: Add module firmware flashing in progress flag to net_device Danielle Ratson
2024-01-22 8:45 ` [RFC PATCH net-next 6/9] net: sfp: Add more extended compliance codes Danielle Ratson
2024-01-23 17:09 ` Russell King (Oracle)
2024-01-22 8:45 ` [RFC PATCH net-next 7/9] ethtool: cmis_cdb: Add a layer for supporting CDB commands Danielle Ratson
2024-01-22 10:31 ` Simon Horman [this message]
2024-01-22 14:35 ` Danielle Ratson
2024-01-22 20:03 ` Simon Horman
2024-01-23 17:17 ` Russell King (Oracle)
2024-01-30 7:55 ` Danielle Ratson
2024-01-22 8:45 ` [RFC PATCH net-next 8/9] ethtool: cmis_fw_update: add a layer for supporting firmware update using CDB Danielle Ratson
2024-01-23 4:44 ` Jakub Kicinski
2024-01-23 12:08 ` Danielle Ratson
2024-01-23 5:07 ` Jakub Kicinski
2024-01-22 8:45 ` [RFC PATCH net-next 9/9] ethtool: Add ability to flash transceiver modules' firmware Danielle Ratson
2024-01-22 10:37 ` Simon Horman
2024-01-22 15:25 ` Danielle Ratson
2024-01-23 5:05 ` Jakub Kicinski
2024-01-23 13:05 ` Danielle Ratson
2024-01-23 15:49 ` Jakub Kicinski
2024-01-24 15:46 ` Danielle Ratson
2024-01-24 17:06 ` Jakub Kicinski
2024-01-23 16:27 ` Russell King (Oracle)
2024-01-24 13:11 ` Danielle Ratson
2024-01-25 21:03 ` Andrew Lunn
2024-01-31 15:48 ` Danielle Ratson
2024-01-31 15:52 ` Danielle Ratson
2024-01-31 16:30 ` Andrew Lunn
2024-04-08 12:50 ` Danielle Ratson
2024-04-08 23:53 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240122103100.GA126470@kernel.org \
--to=horms@kernel.org \
--cc=ahmed.zaki@intel.com \
--cc=corbet@lwn.net \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=idosch@nvidia.com \
--cc=jiri@resnulli.us \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=mlxsw@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul.greenwalt@intel.com \
--cc=petrm@nvidia.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
--cc=sdf@google.com \
--cc=shayagr@amazon.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.