From: Jakub Kicinski <kuba@kernel.org>
To: bjorn@kernel.org
Cc: Jakub Kicinski <kuba@kernel.org>,
danieller@nvidia.com, michael.chan@broadcom.com,
saeedm@nvidia.com, piergiorgio.beruto@gmail.com,
naveenm@marvell.com, maxime.chevallier@bootlin.com,
linux-kselftest@vger.kernel.org, kory.maincent@bootlin.com,
leon@kernel.org, linux-kernel@vger.kernel.org, idosch@nvidia.com,
davem@davemloft.net, shuah@kernel.org, netdev@vger.kernel.org,
edumazet@google.com, o.rempel@pengutronix.de,
pavan.chebbi@broadcom.com, willemb@google.com,
hkelam@marvell.com, horms@kernel.org, linux-rdma@vger.kernel.org,
linux@armlinux.org.uk, andrew+netdev@lunn.ch, tariqt@nvidia.com,
donald.hunter@gmail.com, pabeni@redhat.com
Subject: Re: [net-next,10/11] netdevsim: Add module EEPROM simulation via debugfs
Date: Wed, 11 Mar 2026 19:52:09 -0700 [thread overview]
Message-ID: <20260312025209.605854-1-kuba@kernel.org> (raw)
In-Reply-To: <20260310104743.907818-11-bjorn@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
netdevsim: Add module EEPROM simulation via debugfs
This patch adds get/set_module_eeprom_by_page ethtool ops to netdevsim
for testing kernel features that depend on module EEPROM access. The
EEPROM is backed by a 256-page x 128-byte array exposed via debugfs.
> diff --git a/drivers/net/netdevsim/ethtool.c b/drivers/net/netdevsim/ethtool.c
> index 84bc025885f7..7ef96a747643 100644
> --- a/drivers/net/netdevsim/ethtool.c
> +++ b/drivers/net/netdevsim/ethtool.c
> @@ -247,6 +247,68 @@ static int nsim_set_loopback(struct net_device *dev,
> return 1;
> }
>
> +static u8 *nsim_module_eeprom_ptr(struct netdevsim *ns,
> + const struct ethtool_module_eeprom *page_data,
> + u32 *len)
> +{
> + u32 offset;
> + u8 page;
> +
> + if (page_data->offset < NSIM_MODULE_EEPROM_PAGE_LEN) {
> + page = 0;
> + offset = page_data->offset;
> + } else {
> + page = page_data->page;
^^^^
Does this need bounds checking? The page_data->page value comes from userspace
via ethtool and is used directly as an array index at the return statement
below. The module.pages array is defined as:
u8 pages[NSIM_MODULE_EEPROM_PAGES][NSIM_MODULE_EEPROM_PAGE_LEN]
where NSIM_MODULE_EEPROM_PAGES is 256. A userspace caller could provide a page
number >= 256, leading to an out-of-bounds access:
return ns->ethtool.module.pages[page] + offset;
This can result in reading or writing (via nsim_set_module_eeprom_by_page)
adjacent kernel memory.
> + offset = page_data->offset - NSIM_MODULE_EEPROM_PAGE_LEN;
> + }
> +
> + *len = min_t(u32, page_data->length,
> + NSIM_MODULE_EEPROM_PAGE_LEN - offset);
^^^^^^
Can offset exceed NSIM_MODULE_EEPROM_PAGE_LEN here? When page_data->offset >=
128, the code calculates:
offset = page_data->offset - NSIM_MODULE_EEPROM_PAGE_LEN
If page_data->offset is large (e.g., 300), the resulting offset would be 172.
At the min_t calculation:
NSIM_MODULE_EEPROM_PAGE_LEN - offset = 128 - 172 = -44
This underflows when cast to u32, becoming a large unsigned value. The return
statement then accesses:
ns->ethtool.module.pages[page] + offset
where offset can be > 128, reading past the page boundary. Each page is only
NSIM_MODULE_EEPROM_PAGE_LEN (128) bytes, but offset isn't validated to be
within this range.
> + return ns->ethtool.module.pages[page] + offset;
> +}
> +
> +static int
> +nsim_get_module_eeprom_by_page(struct net_device *dev,
> + const struct ethtool_module_eeprom *page_data,
> + struct netlink_ext_ack *extack)
> +{
> + struct netdevsim *ns = netdev_priv(dev);
> + u32 len;
> + u8 *ptr;
> +
> + if (ns->ethtool.module.get_err)
> + return -ns->ethtool.module.get_err;
> +
> + ptr = nsim_module_eeprom_ptr(ns, page_data, &len);
> + if (!ptr)
> + return -EINVAL;
> +
> + memcpy(page_data->data, ptr, len);
> +
> + return len;
> +}
> +
> +static int
> +nsim_set_module_eeprom_by_page(struct net_device *dev,
> + const struct ethtool_module_eeprom *page_data,
> + struct netlink_ext_ack *extack)
> +{
> + struct netdevsim *ns = netdev_priv(dev);
> + u32 len;
> + u8 *ptr;
> +
> + if (ns->ethtool.module.set_err)
> + return -ns->ethtool.module.set_err;
> +
> + ptr = nsim_module_eeprom_ptr(ns, page_data, &len);
> + if (!ptr)
> + return -EINVAL;
> +
> + memcpy(ptr, page_data->data, len);
> +
> + return 0;
> +}
[ ... ]
> diff --git a/drivers/net/netdevsim/netdevsim.h b/drivers/net/netdevsim/netdevsim.h
> index 2e322b9410d2..f6b2063d41c9 100644
> --- a/drivers/net/netdevsim/netdevsim.h
> +++ b/drivers/net/netdevsim/netdevsim.h
> @@ -82,6 +82,16 @@ struct nsim_ethtool_pauseparam {
> bool report_stats_tx;
> };
>
> +#define NSIM_MODULE_EEPROM_PAGES 256
> +#define NSIM_MODULE_EEPROM_PAGE_LEN 128
> +
> +struct nsim_ethtool_module {
> + u32 get_err;
> + u32 set_err;
> + u8 pages[NSIM_MODULE_EEPROM_PAGES][NSIM_MODULE_EEPROM_PAGE_LEN];
> + struct debugfs_blob_wrapper page_blobs[NSIM_MODULE_EEPROM_PAGES];
> +};
[ ... ]
next prev parent reply other threads:[~2026-03-12 2:52 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 10:47 [PATCH net-next 00/11] ethtool: Generic loopback support Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 01/11] ethtool: Add dump_one_dev callback for per-device sub-iteration Björn Töpel
2026-03-12 2:32 ` Jakub Kicinski
2026-03-13 16:36 ` Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 02/11] ethtool: Add loopback netlink UAPI definitions Björn Töpel
2026-03-11 7:33 ` Maxime Chevallier
2026-03-11 10:39 ` Björn Töpel
2026-03-11 15:30 ` Andrew Lunn
2026-03-11 15:42 ` Maxime Chevallier
2026-03-11 19:37 ` Andrew Lunn
2026-03-12 2:47 ` Jakub Kicinski
2026-03-12 13:46 ` Andrew Lunn
2026-03-13 0:21 ` Jakub Kicinski
2026-03-11 10:50 ` Oleksij Rempel
2026-03-12 2:49 ` Jakub Kicinski
2026-03-11 15:22 ` Andrew Lunn
2026-03-11 15:35 ` Maxime Chevallier
2026-03-11 19:26 ` Andrew Lunn
2026-03-12 2:50 ` Jakub Kicinski
2026-03-12 5:04 ` Oleksij Rempel
2026-03-12 7:49 ` Maxime Chevallier
2026-03-12 8:46 ` Oleksij Rempel
2026-03-12 13:34 ` Andrew Lunn
2026-03-12 13:51 ` Oleksij Rempel
2026-03-12 16:39 ` Maxime Chevallier
2026-03-13 19:11 ` Björn Töpel
2026-03-15 15:09 ` Oleksij Rempel
2026-03-15 16:20 ` Björn Töpel
2026-03-18 15:59 ` Andrew Lunn
2026-03-10 10:47 ` [PATCH net-next 03/11] ethtool: Add loopback GET/SET netlink implementation Björn Töpel
2026-03-12 2:51 ` [net-next,03/11] " Jakub Kicinski
2026-03-10 10:47 ` [PATCH net-next 04/11] ethtool: Add CMIS loopback helpers for module loopback control Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 05/11] selftests: drv-net: Add loopback driver test Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 06/11] ethtool: Add MAC loopback support via ethtool_ops Björn Töpel
2026-03-11 6:04 ` [PATCH 6/11] " Naveen Mamindlapalli
2026-03-10 10:47 ` [PATCH net-next 07/11] netdevsim: Add MAC loopback simulation Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 08/11] selftests: drv-net: Add MAC loopback netdevsim test Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 09/11] MAINTAINERS: Add entry for ethtool loopback Björn Töpel
2026-03-10 10:47 ` [PATCH net-next 10/11] netdevsim: Add module EEPROM simulation via debugfs Björn Töpel
2026-03-12 2:52 ` Jakub Kicinski [this message]
2026-03-10 10:47 ` [PATCH net-next 11/11] selftests: drv-net: Add CMIS loopback netdevsim test Björn Töpel
2026-03-11 6:18 ` [PATCH net-next 00/11] ethtool: Generic loopback support Naveen Mamindlapalli
2026-03-11 10:24 ` Björn Töpel
2026-03-12 2:53 ` Jakub Kicinski
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=20260312025209.605854-1-kuba@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bjorn@kernel.org \
--cc=danieller@nvidia.com \
--cc=davem@davemloft.net \
--cc=donald.hunter@gmail.com \
--cc=edumazet@google.com \
--cc=hkelam@marvell.com \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=kory.maincent@bootlin.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=michael.chan@broadcom.com \
--cc=naveenm@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=piergiorgio.beruto@gmail.com \
--cc=saeedm@nvidia.com \
--cc=shuah@kernel.org \
--cc=tariqt@nvidia.com \
--cc=willemb@google.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.