[bug report] net: ethtool: Introduce per-PHY DUMP operations

[bug report] net: ethtool: Introduce per-PHY DUMP operations

[Dan Carpenter]

[ Smatch checking is paused while we raise funding.  #SadFace
  https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]

Hello Maxime Chevallier,

Commit 172265b44cd3 ("net: ethtool: Introduce per-PHY DUMP
operations") from May 2, 2025 (linux-next), leads to the following
Smatch static checker warning:

	net/ethtool/netlink.c:714 ethnl_perphy_start()
	error: buffer overflow 'ethnl_default_requests' 52 <= 255 user_rl='0-255' uncapped

net/ethtool/netlink.c
    700 static int ethnl_perphy_start(struct netlink_callback *cb)
    701 {
    702         struct ethnl_perphy_dump_ctx *phy_ctx = ethnl_perphy_dump_context(cb);
    703         const struct genl_dumpit_info *info = genl_dumpit_info(cb);
    704         struct ethnl_dump_ctx *ctx = &phy_ctx->ethnl_ctx;
    705         struct ethnl_reply_data *reply_data;
    706         const struct ethnl_request_ops *ops;
    707         struct ethnl_req_info *req_info;
    708         struct genlmsghdr *ghdr;
    709         int ret;
    710 
    711         BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
    712 
    713         ghdr = nlmsg_data(cb->nlh);
--> 714         ops = ethnl_default_requests[ghdr->cmd];

Smatch thinks nlmsg_data() is untrusted data, so it could be out of bounds.
It's a u8, but there are only 52 elements in the ethnl_default_requests[]
array.

    715         if (WARN_ONCE(!ops, "cmd %u has no ethnl_request_ops\n", ghdr->cmd))
    716                 return -EOPNOTSUPP;
    717         req_info = kzalloc(ops->req_info_size, GFP_KERNEL);
    718         if (!req_info)
    719                 return -ENOMEM;
    720         reply_data = kmalloc(ops->reply_data_size, GFP_KERNEL);
    721         if (!reply_data) {
    722                 ret = -ENOMEM;
    723                 goto free_req_info;
    724         }
    725 
    726         /* Unlike per-dev dump, don't ignore dev. The dump handler
    727          * will notice it and dump PHYs from given dev. We only keep track of
    728          * the dev's ifindex, .dumpit() will grab and release the netdev itself.
    729          */
    730         ret = ethnl_default_parse(req_info, &info->info, ops, false);
    731         if (ret < 0)
    732                 goto free_reply_data;
    733         if (req_info->dev) {
    734                 phy_ctx->ifindex = req_info->dev->ifindex;
    735                 netdev_put(req_info->dev, &req_info->dev_tracker);
    736                 req_info->dev = NULL;
    737         }
    738 
    739         ctx->ops = ops;
    740         ctx->req_info = req_info;
    741         ctx->reply_data = reply_data;
    742         ctx->pos_ifindex = 0;
    743 
    744         return 0;
    745 
    746 free_reply_data:
    747         kfree(reply_data);
    748 free_req_info:
    749         kfree(req_info);
    750 
    751         return ret;
    752 }

regards,
dan carpenter

[bug report] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver

[Dan Carpenter]

[ Smatch checking is paused while we raise funding.  #SadFace
  https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]

Hello Stephan Gerhold,

Commit 21a0ffd9b38c ("net: wwan: Add Qualcomm BAM-DMUX WWAN network
driver") from Nov 27, 2021 (linux-next), leads to the following
Smatch static checker warning:

	drivers/net/wwan/qcom_bam_dmux.c:505 bam_dmux_cmd_data()
	error: buffer overflow 'dmux->netdevs' 8 <= 255 user_rl='0-255' uncapped

drivers/net/wwan/qcom_bam_dmux.c
    500 static void bam_dmux_cmd_data(struct bam_dmux_skb_dma *skb_dma)
    501 {
    502         struct bam_dmux *dmux = skb_dma->dmux;
    503         struct sk_buff *skb = skb_dma->skb;
    504         struct bam_dmux_hdr *hdr = (struct bam_dmux_hdr *)skb->data;
--> 505         struct net_device *netdev = dmux->netdevs[hdr->ch];
                                                          ^^^^^^^
Smatch thinks skb->data is untrusted.  This is the rx path.

    506 
    507         if (!netdev || !netif_running(netdev)) {
    508                 dev_warn(dmux->dev, "Data for inactive channel %u\n", hdr->ch);
    509                 return;
    510         }
    511 

regards,
dan carpenter

[bug report] net: ethernet: ti: am65-cpsw: enable bc/mc storm prevention support

[Dan Carpenter]

[ Smatch checking is paused while we raise funding.  #SadFace
  https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]

Hello Grygorii Strashko,

Commit 5ec836be11b3 ("net: ethernet: ti: am65-cpsw: enable bc/mc
storm prevention support") from Apr 12, 2022 (linux-next), leads to
the following Smatch static checker warning:

	drivers/net/ethernet/ti/am65-cpsw-qos.c:1126 am65_cpsw_qos_configure_clsflower()
	warn: iterator 'i' not incremented

drivers/net/ethernet/ti/am65-cpsw-qos.c
    1118 static int am65_cpsw_qos_configure_clsflower(struct am65_cpsw_port *port,
    1119                                              struct flow_cls_offload *cls)
    1120 {
    1121         struct flow_rule *rule = flow_cls_offload_flow_rule(cls);
    1122         struct netlink_ext_ack *extack = cls->common.extack;
    1123         const struct flow_action_entry *act;
    1124         int i, ret;
    1125 
--> 1126         flow_action_for_each(i, act, &rule->action) {

This loop only iterates one time.  Is that intentional?  We could
use "act = flow_action_first_entry_geti(&rule->action);" if we just
want the first entry.

    1127                 switch (act->id) {
    1128                 case FLOW_ACTION_POLICE:
    1129                         ret = am65_cpsw_qos_clsflower_policer_validate(&rule->action, act, extack);
    1130                         if (ret)
    1131                                 return ret;
    1132 
    1133                         return am65_cpsw_qos_clsflower_add_policer(port, extack, cls,
    1134                                                                    act->police.rate_pkt_ps);
    1135                 default:
    1136                         NL_SET_ERR_MSG_MOD(extack,
    1137                                            "Action not supported");
    1138                         return -EOPNOTSUPP;
    1139                 }
    1140         }
    1141         return -EOPNOTSUPP;
    1142 }

regards,
dan carpenter

[bug report] xfrm: always fail xfrm_dev_{state,policy}_flush_secctx_check()

[Dan Carpenter]

[ Smatch checking is paused while we raise funding.  #SadFace
  https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]

Hello Tetsuo Handa,

Commit 638361ad7ab2 ("xfrm: always fail
xfrm_dev_{state,policy}_flush_secctx_check()") from Feb 2, 2026
(linux-next), leads to the following Smatch static checker warning:

	net/xfrm/xfrm_state.c:898 xfrm_dev_state_flush_secctx_check()
	warn: was '== (-1)' instead of '='

net/xfrm/xfrm_state.c
    888         int i, err = 0;
    889 
    890         for (i = 0; i <= net->xfrm.state_hmask; i++) {
    891                 struct xfrm_state *x;
    892                 struct xfrm_dev_offload *xso;
    893 
    894                 hlist_for_each_entry(x, net->xfrm.state_bydst+i, bydst) {
    895                         xso = &x->xso;
    896 
    897                         if (xso->dev == dev &&
--> 898                             (err = -EPERM) != 0) {
                                         ^
= vs == bug.

    899                                 pr_info("%s: LSM policy is rejecting this operation.\n", __func__);
    900                                 dump_stack();
    901                                 xfrm_audit_state_delete(x, 0, task_valid);
    902                                 return err;
    903                         }
    904                 }
    905         }
    906 
    907         return err;
    908 }

regards,
dan carpenter

Re: [bug report] xfrm: always fail xfrm_dev_{state,policy}_flush_secctx_check()

[Tetsuo Handa]

On 2026/02/06 22:41, Dan Carpenter wrote:
> [ Smatch checking is paused while we raise funding.  #SadFace
>   https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]
> 
> Hello Tetsuo Handa,
> 
> Commit 638361ad7ab2 ("xfrm: always fail
> xfrm_dev_{state,policy}_flush_secctx_check()") from Feb 2, 2026
> (linux-next), leads to the following Smatch static checker warning:
> 
> 	net/xfrm/xfrm_state.c:898 xfrm_dev_state_flush_secctx_check()
> 	warn: was '== (-1)' instead of '='

Thank you, but this change is intended for demonstrating to SELinux people that
making xfrm_dev_{state,policy}_flush() no-op results in hung task bug
( https://lkml.kernel.org/r/f9b88268-03dc-4356-8b31-0bab73cc9b1e@I-love.SAKURA.ne.jp ).

That change is already removed, and we are waiting for
https://lkml.kernel.org/r/2ec9c137-79a5-4562-8587-43dd2633f116@I-love.SAKURA.ne.jp
to be applied.

Re: [bug report] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver

[Stephan Gerhold]

Hi Dan,

On Fri, Feb 06, 2026 at 04:38:30PM +0300, Dan Carpenter wrote:
> [ Smatch checking is paused while we raise funding.  #SadFace
>   https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]
> 
> Hello Stephan Gerhold,
> 
> Commit 21a0ffd9b38c ("net: wwan: Add Qualcomm BAM-DMUX WWAN network
> driver") from Nov 27, 2021 (linux-next), leads to the following
> Smatch static checker warning:
> 
> 	drivers/net/wwan/qcom_bam_dmux.c:505 bam_dmux_cmd_data()
> 	error: buffer overflow 'dmux->netdevs' 8 <= 255 user_rl='0-255' uncapped
> 
> drivers/net/wwan/qcom_bam_dmux.c
>     500 static void bam_dmux_cmd_data(struct bam_dmux_skb_dma *skb_dma)
>     501 {
>     502         struct bam_dmux *dmux = skb_dma->dmux;
>     503         struct sk_buff *skb = skb_dma->skb;
>     504         struct bam_dmux_hdr *hdr = (struct bam_dmux_hdr *)skb->data;
> --> 505         struct net_device *netdev = dmux->netdevs[hdr->ch];
>                                                           ^^^^^^^
> Smatch thinks skb->data is untrusted.  This is the rx path.
> 

Thanks a lot for the report!

I believe this is not a problem in practice, since there is an existing
check for this in bam_dmux_rx_callback() (which is the only function
that calls bam_dmux_cmd_data()):

	if (hdr->ch >= BAM_DMUX_NUM_CH) {
		dev_dbg(dmux->dev, "Unsupported channel: %u\n", hdr->ch);
		goto out;
	}

	switch (hdr->cmd) {
	case BAM_DMUX_CMD_DATA:
		bam_dmux_cmd_data(skb_dma);
		break;

Is that something Smatch should be able to detect?

Thanks,
Stephan

Re: [bug report] net: wwan: Add Qualcomm BAM-DMUX WWAN network driver

[Dan Carpenter]

On Fri, Feb 06, 2026 at 04:12:17PM +0100, Stephan Gerhold wrote:
> Hi Dan,
> 
> On Fri, Feb 06, 2026 at 04:38:30PM +0300, Dan Carpenter wrote:
> > [ Smatch checking is paused while we raise funding.  #SadFace
> >   https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]
> > 
> > Hello Stephan Gerhold,
> > 
> > Commit 21a0ffd9b38c ("net: wwan: Add Qualcomm BAM-DMUX WWAN network
> > driver") from Nov 27, 2021 (linux-next), leads to the following
> > Smatch static checker warning:
> > 
> > 	drivers/net/wwan/qcom_bam_dmux.c:505 bam_dmux_cmd_data()
> > 	error: buffer overflow 'dmux->netdevs' 8 <= 255 user_rl='0-255' uncapped
> > 
> > drivers/net/wwan/qcom_bam_dmux.c
> >     500 static void bam_dmux_cmd_data(struct bam_dmux_skb_dma *skb_dma)
> >     501 {
> >     502         struct bam_dmux *dmux = skb_dma->dmux;
> >     503         struct sk_buff *skb = skb_dma->skb;
> >     504         struct bam_dmux_hdr *hdr = (struct bam_dmux_hdr *)skb->data;
> > --> 505         struct net_device *netdev = dmux->netdevs[hdr->ch];
> >                                                           ^^^^^^^
> > Smatch thinks skb->data is untrusted.  This is the rx path.
> > 
> 
> Thanks a lot for the report!
> 
> I believe this is not a problem in practice, since there is an existing
> check for this in bam_dmux_rx_callback() (which is the only function
> that calls bam_dmux_cmd_data()):
> 
> 	if (hdr->ch >= BAM_DMUX_NUM_CH) {
> 		dev_dbg(dmux->dev, "Unsupported channel: %u\n", hdr->ch);
> 		goto out;
> 	}
> 
> 	switch (hdr->cmd) {
> 	case BAM_DMUX_CMD_DATA:
> 		bam_dmux_cmd_data(skb_dma);
> 		break;
> 
> Is that something Smatch should be able to detect?
> 

Ah, you are right.  Thanks.

The problem is that skb->data is a buffer of u8 data.  Smatch does cross
function analysis, but it treats a buffer like that as opaque data.

Btw, I see that this code is actually from five years ago so I don't know
why it's showing up as a warning now.  :/  Sorry about that.

regards,
dan carpenter

Re: [bug report] net: ethtool: Introduce per-PHY DUMP operations

[Maxime Chevallier]

Hi Dan,

On 06/02/2026 14:38, Dan Carpenter wrote:
> [ Smatch checking is paused while we raise funding.  #SadFace
>   https://lore.kernel.org/all/aTaiGSbWZ9DJaGo7@stanley.mountain/ -dan ]
> 
> Hello Maxime Chevallier,
> 
> Commit 172265b44cd3 ("net: ethtool: Introduce per-PHY DUMP
> operations") from May 2, 2025 (linux-next), leads to the following
> Smatch static checker warning:
> 
> 	net/ethtool/netlink.c:714 ethnl_perphy_start()
> 	error: buffer overflow 'ethnl_default_requests' 52 <= 255 user_rl='0-255' uncapped
> 
> net/ethtool/netlink.c
>     700 static int ethnl_perphy_start(struct netlink_callback *cb)
>     701 {
>     702         struct ethnl_perphy_dump_ctx *phy_ctx = ethnl_perphy_dump_context(cb);
>     703         const struct genl_dumpit_info *info = genl_dumpit_info(cb);
>     704         struct ethnl_dump_ctx *ctx = &phy_ctx->ethnl_ctx;
>     705         struct ethnl_reply_data *reply_data;
>     706         const struct ethnl_request_ops *ops;
>     707         struct ethnl_req_info *req_info;
>     708         struct genlmsghdr *ghdr;
>     709         int ret;
>     710 
>     711         BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
>     712 
>     713         ghdr = nlmsg_data(cb->nlh);
> --> 714         ops = ethnl_default_requests[ghdr->cmd];
> 
> Smatch thinks nlmsg_data() is untrusted data, so it could be out of bounds.
> It's a u8, but there are only 52 elements in the ethnl_default_requests[]
> array.

I see, then we also have the same problem in ethnl_default_start().

I'd expect the genl part to validate cmd (I haven't checked yet), but we
do have a WARN_ONCE just below for the case 'cmd' is wrong, so we could
definitely add some more sanity checks before accessing
ethnl_default_requests[].

I'll look further into that and send the relevant fixes :)

Thanks for the report,

Maxime

Re: [bug report] net: ethtool: Introduce per-PHY DUMP operations

[Dan Carpenter]

On Fri, Feb 06, 2026 at 06:04:36PM +0100, Maxime Chevallier wrote:
> > net/ethtool/netlink.c
> >     700 static int ethnl_perphy_start(struct netlink_callback *cb)
> >     701 {
> >     702         struct ethnl_perphy_dump_ctx *phy_ctx = ethnl_perphy_dump_context(cb);
> >     703         const struct genl_dumpit_info *info = genl_dumpit_info(cb);
> >     704         struct ethnl_dump_ctx *ctx = &phy_ctx->ethnl_ctx;
> >     705         struct ethnl_reply_data *reply_data;
> >     706         const struct ethnl_request_ops *ops;
> >     707         struct ethnl_req_info *req_info;
> >     708         struct genlmsghdr *ghdr;
> >     709         int ret;
> >     710 
> >     711         BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
> >     712 
> >     713         ghdr = nlmsg_data(cb->nlh);
> > --> 714         ops = ethnl_default_requests[ghdr->cmd];
> > 
> > Smatch thinks nlmsg_data() is untrusted data, so it could be out of bounds.
> > It's a u8, but there are only 52 elements in the ethnl_default_requests[]
> > array.
> 
> I see, then we also have the same problem in ethnl_default_start().
> 
> I'd expect the genl part to validate cmd (I haven't checked yet), but we
> do have a WARN_ONCE just below for the case 'cmd' is wrong, so we could
> definitely add some more sanity checks before accessing
> ethnl_default_requests[].

The WARN_ONCE() doesn't doesn't work as bounds checking since there is
no guarantee that the array will be followed by NULL pointers.  I didn't
see a bounds check for this, but I'm not an expert.

netlink_rcv_skb() <- receives untrusted data nlh = nlmsg_hdr(skb);
-> nfnetlink_rcv_msg() <- calls nc->call()
   -> ip_set_dump()
      -> netlink_dump_start()
         -> __netlink_dump_start() <- calls control->start(cb);
            -> genl_start() <- this is where the validation would be
                               when we call
                               genl_family_rcv_msg_attrs_parse()
               -> ethnl_perphy_start()

Also the WARN_ONCE() warns if we try to do a cmd which doesn't have a
matching operation in ethnl_default_requests[].  Every time we check
for missing commands it triggers a WARN_ONCE().  There are quite a few
which don't have a handler so I'm surprised that syzbot doesn't trigger
the warning and complain.  Here is a list of commands without a
handler:

ETHTOOL_MSG_USER_NONE, 
ETHTOOL_MSG_FEATURES_SET,
ETHTOOL_MSG_CABLE_TEST_ACT,
ETHTOOL_MSG_CABLE_TEST_TDR_ACT,
ETHTOOL_MSG_TUNNEL_INFO_GET,
ETHTOOL_MSG_MODULE_FW_FLASH_ACT,
ETHTOOL_MSG_RSS_CREATE_ACT,
ETHTOOL_MSG_RSS_DELETE_ACT,

regards,
dan carpenter

Re: [bug report] net: ethtool: Introduce per-PHY DUMP operations

[Maxime Chevallier]

Hi Dan,

On 09/02/2026 08:09, Dan Carpenter wrote:
> On Fri, Feb 06, 2026 at 06:04:36PM +0100, Maxime Chevallier wrote:
>>> net/ethtool/netlink.c
>>>     700 static int ethnl_perphy_start(struct netlink_callback *cb)
>>>     701 {
>>>     702         struct ethnl_perphy_dump_ctx *phy_ctx = ethnl_perphy_dump_context(cb);
>>>     703         const struct genl_dumpit_info *info = genl_dumpit_info(cb);
>>>     704         struct ethnl_dump_ctx *ctx = &phy_ctx->ethnl_ctx;
>>>     705         struct ethnl_reply_data *reply_data;
>>>     706         const struct ethnl_request_ops *ops;
>>>     707         struct ethnl_req_info *req_info;
>>>     708         struct genlmsghdr *ghdr;
>>>     709         int ret;
>>>     710 
>>>     711         BUILD_BUG_ON(sizeof(*ctx) > sizeof(cb->ctx));
>>>     712 
>>>     713         ghdr = nlmsg_data(cb->nlh);
>>> --> 714         ops = ethnl_default_requests[ghdr->cmd];
>>>
>>> Smatch thinks nlmsg_data() is untrusted data, so it could be out of bounds.
>>> It's a u8, but there are only 52 elements in the ethnl_default_requests[]
>>> array.
>>
>> I see, then we also have the same problem in ethnl_default_start().
>>
>> I'd expect the genl part to validate cmd (I haven't checked yet), but we
>> do have a WARN_ONCE just below for the case 'cmd' is wrong, so we could
>> definitely add some more sanity checks before accessing
>> ethnl_default_requests[].
> 
> The WARN_ONCE() doesn't doesn't work as bounds checking since there is
> no guarantee that the array will be followed by NULL pointers.  I didn't
> see a bounds check for this, but I'm not an expert.
> 
> netlink_rcv_skb() <- receives untrusted data nlh = nlmsg_hdr(skb);
> -> nfnetlink_rcv_msg() <- calls nc->call()
>    -> ip_set_dump()
>       -> netlink_dump_start()
>          -> __netlink_dump_start() <- calls control->start(cb);
>             -> genl_start() <- this is where the validation would be
>                                when we call
>                                genl_family_rcv_msg_attrs_parse()
>                -> ethnl_perphy_start()
> 
> Also the WARN_ONCE() warns if we try to do a cmd which doesn't have a
> matching operation in ethnl_default_requests[].  Every time we check
> for missing commands it triggers a WARN_ONCE().  There are quite a few
> which don't have a handler so I'm surprised that syzbot doesn't trigger
> the warning and complain.  Here is a list of commands without a
> handler:
> 
> ETHTOOL_MSG_USER_NONE, 
> ETHTOOL_MSG_FEATURES_SET,
> ETHTOOL_MSG_CABLE_TEST_ACT,
> ETHTOOL_MSG_CABLE_TEST_TDR_ACT,
> ETHTOOL_MSG_TUNNEL_INFO_GET,
> ETHTOOL_MSG_MODULE_FW_FLASH_ACT,
> ETHTOOL_MSG_RSS_CREATE_ACT,
> ETHTOOL_MSG_RSS_DELETE_ACT,

While these commands don't have ethnl_request_ops handlers, they still
have a genetlink handler, see the ethtool_genl_ops array [1]

The ethnl_request_ops are there to provide a framework for ethtool
netlink commands, as most of them have roughly the same behaviour of
needing to grab some info from the netdev/phy_device under rtnl, then
populate a netlink message based on that outside rtnl.

It's expected that not all ethnl commands use that ethnl framework as
some behave in a manner that don't fit the ethnl scaffholding. In the
end, the "cmd" validation is done by the generic netlink infrastructure,
that's why we don't see reports from fuzzing bots.

The WARN_ONCE we see in ethnl_default_start() and ethnl_perphy_start()
is there in case a programmer tries to use the ethnl framework without
having the ethnl ops populated.

[1] :
https://elixir.bootlin.com/linux/v6.18.6/source/net/ethtool/netlink.c#L1132

In reality, we should never end-up with an out of bounds cmd as the
validation will occur higher-up, in the genetlink part.

However, I'm OK with adding a check, or a least a comment :)

Maxime

Re: [bug report] net: ethtool: Introduce per-PHY DUMP operations

[Andrew Lunn]

> > ETHTOOL_MSG_USER_NONE, 
> > ETHTOOL_MSG_FEATURES_SET,
> > ETHTOOL_MSG_CABLE_TEST_ACT,
> > ETHTOOL_MSG_CABLE_TEST_TDR_ACT,
> > ETHTOOL_MSG_TUNNEL_INFO_GET,
> > ETHTOOL_MSG_MODULE_FW_FLASH_ACT,
> > ETHTOOL_MSG_RSS_CREATE_ACT,
> > ETHTOOL_MSG_RSS_DELETE_ACT,
> 
> While these commands don't have ethnl_request_ops handlers, they still
> have a genetlink handler, see the ethtool_genl_ops array [1]

At least for the *_ACT commands, they are not expected in the
userspace->kernel space direction. They should only be sent by the
kernel to user space, to indicate some action has been performed, or
happened. I don't know the netlink code too well, but i assume there
is something which will throw out such commands if sent to the kernel,
without even looking at the parameters?

	Andrew

Re: [bug report] net: ethtool: Introduce per-PHY DUMP operations

[Dan Carpenter]

On Mon, Feb 09, 2026 at 02:10:38PM +0100, Andrew Lunn wrote:
> > > ETHTOOL_MSG_USER_NONE, 
> > > ETHTOOL_MSG_FEATURES_SET,
> > > ETHTOOL_MSG_CABLE_TEST_ACT,
> > > ETHTOOL_MSG_CABLE_TEST_TDR_ACT,
> > > ETHTOOL_MSG_TUNNEL_INFO_GET,
> > > ETHTOOL_MSG_MODULE_FW_FLASH_ACT,
> > > ETHTOOL_MSG_RSS_CREATE_ACT,
> > > ETHTOOL_MSG_RSS_DELETE_ACT,
> > 
> > While these commands don't have ethnl_request_ops handlers, they still
> > have a genetlink handler, see the ethtool_genl_ops array [1]
> 
> At least for the *_ACT commands, they are not expected in the
> userspace->kernel space direction. They should only be sent by the
> kernel to user space, to indicate some action has been performed, or
> happened. I don't know the netlink code too well, but i assume there
> is something which will throw out such commands if sent to the kernel,
> without even looking at the parameters?

Ah.  Got it.  Thanks!


regards,
dan carpenter