From: Jakub Kicinski <kuba@kernel.org>
To: Danielle Ratson <danieller@nvidia.com>
Cc: <netdev@vger.kernel.org>, <davem@davemloft.net>,
<edumazet@google.com>, <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 9/9] ethtool: Add ability to flash transceiver modules' firmware
Date: Mon, 22 Jan 2024 21:05:34 -0800 [thread overview]
Message-ID: <20240122210534.5054b202@kernel.org> (raw)
In-Reply-To: <20240122084530.32451-10-danieller@nvidia.com>
On Mon, 22 Jan 2024 10:45:30 +0200 Danielle Ratson wrote:
> #include <linux/ethtool.h>
> +#include <linux/sfp.h>
> +#include <linux/firmware.h>
alphabetical order, please
> +static int
> +module_flash_fw_schedule(struct net_device *dev,
> + struct ethtool_module_fw_flash_params *params,
> + struct netlink_ext_ack *extack)
> +{
> + const struct ethtool_ops *ops = dev->ethtool_ops;
> + struct ethtool_module_fw_flash *module_fw;
> + int err;
> +
> + if (!ops->set_module_eeprom_by_page ||
> + !ops->get_module_eeprom_by_page) {
> + NL_SET_ERR_MSG(extack,
> + "Flashing module firmware is not supported by this device");
> + return -EOPNOTSUPP;
> + }
> +
> + if (dev->module_fw_flash_in_progress) {
> + NL_SET_ERR_MSG(extack, "Module firmware flashing already in progress");
> + return -EBUSY;
> + }
> +
> + module_fw = kzalloc(sizeof(*module_fw), GFP_KERNEL);
> + if (!module_fw)
> + return -ENOMEM;
> +
> + module_fw->params = *params;
> + err = request_firmware(&module_fw->fw, module_fw->params.file_name,
request_firmware_direct() ? I think udev timeout is 30 sec and we're
holding rtnl_lock.. I don't remember why we didn't use that in devlink
> + &dev->dev);
> + if (err) {
> + NL_SET_ERR_MSG(extack,
> + "Failed to request module firmware image");
> + goto err_request_firmware;
> + }
> +
> + err = module_flash_fw_work_init(module_fw, dev, extack);
> + if (err < 0) {
> + NL_SET_ERR_MSG(extack,
> + "Flashing module firmware is not supported by this device");
> + goto err_work_init;
> + }
> +
> + dev->module_fw_flash_in_progress = true;
What does this protect us from?
> +static int module_flash_fw(struct net_device *dev, struct nlattr **tb,
> + struct netlink_ext_ack *extack)
> +{
> + struct ethtool_module_fw_flash_params params = {};
> + struct nlattr *attr;
> +
> + if (!tb[ETHTOOL_A_MODULE_FW_FLASH_FILE_NAME]) {
> + NL_SET_ERR_MSG_ATTR(extack,
GENL_REQ_ATTR_CHECK, and you can check it in the caller,
before taking rtnl_lock.
> + tb[ETHTOOL_A_MODULE_FW_FLASH_FILE_NAME],
> + "File name attribute is missing");
> + return -EINVAL;
> + }
> +
> + params.file_name =
> + nla_data(tb[ETHTOOL_A_MODULE_FW_FLASH_FILE_NAME]);
Hm. I think you copy the param struct by value to the work container.
nla_data() is in the skb which is going to get freed after _ACT returns.
So if anyone tries to access the name from the work it's going to UAF?
> +
> + attr = tb[ETHTOOL_A_MODULE_FW_FLASH_PASSWORD];
> + if (attr) {
> + params.password = cpu_to_be32(nla_get_u32(attr));
> + params.password_valid = true;
> + }
> +
> + return module_flash_fw_schedule(dev, ¶ms, extack);
> +}
next prev parent reply other threads:[~2024-01-23 5:05 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
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 [this message]
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=20240122210534.5054b202@kernel.org \
--to=kuba@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=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.