On 10/2/26 15:28, [email protected] wrote:
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) 
to consider:
- [High] ice: Use-After-Free in ice_setup_mc_magic_wake() during concurrent 
devlink reload
--

commit 6cf8b519dd4de7f3996192dbff4ffe7afc4d34f8
Author: Petr Oros <[email protected]>

ice: program multicast magic wake before tearing down the main VSI

This commit moves the ice_setup_mc_magic_wake() call earlier in ice_remove()
before device structures are torn down. It fixes an issue where WoL magic
packet wake was not set up correctly because it was being called after
ice_deinit().

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c 
b/drivers/net/ethernet/intel/ice/ice_main.c
index b121faa345c1a..857ba7d92b140 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -5465,6 +5465,8 @@ static void ice_remove(struct pci_dev *pdev)
        if (!ice_is_safe_mode(pf))
                ice_remove_arfs(pf);
+ ice_setup_mc_magic_wake(pf);
+
        devl_lock(priv_to_devlink(pf));
[Severity: High]
By moving ice_setup_mc_magic_wake() outside of devl_lock(), is it exposed to
concurrent devlink operations like reload?

If a devlink reload operation executes concurrently with the driver's removal
routine when Wake-on-LAN is enabled, the reload can call ice_unload() and
ice_decfg_netdev(). This unregisters and frees the netdev.

A devlink reload can not run concurrently with ice_remove(). Since
commit bf6b200bc80d18 ("devlink: Acquire device lock during reload
command") the reload takes the device lock before the devlink instance
lock, and both the PCI unbind path and device_shutdown() hold that same
device lock for the whole of ice_remove().


When ice_setup_mc_magic_wake() runs unprotected by the devlink lock, can it
experience a use-after-free when attempting to read the freed netdev's MAC
address?

drivers/net/ethernet/intel/ice/ice_main.c:ice_setup_mc_magic_wake() {
     ...
        if (vsi->netdev)
                ether_addr_copy(mac_addr, vsi->netdev->dev_addr);
     ...
}

Would it be safer to place the ice_setup_mc_magic_wake() call after acquiring
the devlink lock?
No, the netdev can not go away underneath ice_setup_mc_magic_wake()
regardless of where the devlink lock is taken in ice_remove().


        ice_dealloc_all_dynamic_ports(pf);
        ice_deinit_devlink(pf);
@@ -5475,7 +5477,6 @@ static void ice_remove(struct pci_dev *pdev)
        ice_deinit(pf);
        ice_vsi_release_all(pf);
- ice_setup_mc_magic_wake(pf);
        ice_set_wake(pf);
ice_adapter_put(pdev);

Reply via email to