netdev - Re: [PATCH net-next 1/3] net: dsa: cpu_dp->orig_ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <da37b219-1606-4378-9636-9512700c4b80@lunn.ch>
Date: Mon, 24 Nov 2025 00:47:09 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 1/3] net: dsa: cpu_dp->orig_ethtool_ops might be
 NULL

On Sat, Nov 22, 2025 at 01:23:09PM +0200, Vladimir Oltean wrote:
> In theory this would have been seen by now, but it seems that all
> drivers used as DSA conduit interfaces thus far have had ethtool_ops
> set, and it's hard to even find modern Ethernet drivers (and not VF
> ones) which don't use ethtool.
> 
> Here is the unfiltered list of drivers which register any sort of
> net_device but don't set its ethtool_ops pointer. I don't think any of
> them 'risks' being used as a DSA conduit, maybe except for moxart,
> rnpbge and icssm, I'm not sure.
> 
> - drivers/net/can/dev/dev.c
> - drivers/net/wwan/qcom_bam_dmux.c
> - drivers/net/wwan/t7xx/t7xx_netdev.c
> - drivers/net/arcnet/arcnet.c
> - drivers/net/hamradio/
> - drivers/net/slip/slip.c
> - drivers/net/ethernet/ezchip/nps_enet.c
> - drivers/net/ethernet/moxa/moxart_ether.c
> - drivers/net/ethernet/wangxun/txgbevf/txgbevf_main.c
> - drivers/net/ethernet/wangxun/ngbevf/ngbevf_main.c
> - drivers/net/ethernet/huawei/hinic3/hinic3_main.c
> - drivers/net/ethernet/i825xx/
> - drivers/net/ethernet/ti/icssm/icssm_prueth.c
> - drivers/net/ethernet/seeq/
> - drivers/net/ethernet/litex/litex_liteeth.c
> - drivers/net/ethernet/sunplus/spl2sw_driver.c
> - drivers/net/ethernet/mucse/rnpgbe/rnpgbe_main.c
> - drivers/net/ipa/
> - drivers/net/wireless/microchip/wilc1000/
> - drivers/net/wireless/mediatek/mt76/dma.c
> - drivers/net/wireless/ath/ath12k/
> - drivers/net/wireless/ath/ath11k/
> - drivers/net/wireless/ath/ath6kl/
> - drivers/net/wireless/ath/ath10k/
> - drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
> - drivers/net/wireless/virtual/mac80211_hwsim.c
> - drivers/net/wireless/quantenna/qtnfmac/pcie/pcie.c
> - drivers/net/wireless/realtek/rtw89/core.c
> - drivers/net/wireless/realtek/rtw88/pci.c
> - drivers/net/caif/
> - drivers/net/plip/
> - drivers/net/wan/
> - drivers/net/mctp/
> - drivers/net/ppp/
> - drivers/net/thunderbolt/
> 
> Nonetheless, it's good for the framework not to make such assumptions,
> and not panic when coming across such kind of host device in the future.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew