| Message ID | 20230613192220.159407-1-pchelkin@ispras.ru (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 0c0cf3db83f8c7c9bb141c2771a34043bcf952ef |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: macsec: fix double free of percpu stats | expand |
On Tue, 13 Jun 2023 22:22:20 +0300 Fedor Pchelkin wrote: > Inside macsec_add_dev() we free percpu macsec->secy.tx_sc.stats and > macsec->stats on some of the memory allocation failure paths. However, the > net_device is already registered to that moment: in macsec_newlink(), just > before calling macsec_add_dev(). This means that during unregister process > its priv_destructor - macsec_free_netdev() - will be called and will free > the stats again. > > Remove freeing percpu stats inside macsec_add_dev() because > macsec_free_netdev() will correctly free the already allocated ones. The > pointers to unallocated stats stay NULL, and free_percpu() treats that > correctly. What prevents the device from being opened and used before macsec_add_dev() has finished? I think we need a fix which would move this code before register_netdev(), instead :(
2023-06-13, 20:01:50 -0700, Jakub Kicinski wrote: > On Tue, 13 Jun 2023 22:22:20 +0300 Fedor Pchelkin wrote: > > Inside macsec_add_dev() we free percpu macsec->secy.tx_sc.stats and > > macsec->stats on some of the memory allocation failure paths. However, the > > net_device is already registered to that moment: in macsec_newlink(), just > > before calling macsec_add_dev(). This means that during unregister process > > its priv_destructor - macsec_free_netdev() - will be called and will free > > the stats again. > > > > Remove freeing percpu stats inside macsec_add_dev() because > > macsec_free_netdev() will correctly free the already allocated ones. The > > pointers to unallocated stats stay NULL, and free_percpu() treats that > > correctly. > > What prevents the device from being opened and used before > macsec_add_dev() has finished? I think we need a fix which > would move this code before register_netdev(), instead :( Can the device be opened in parallel? We're under rtnl here. If we want to move that code, then we'll also have to move the eth_hw_addr_inherit call that's currently in macsec's ndo_init: in case the user didn't give an SCI, we have to make it up based on the device's mac address (dev_to_sci(dev, ...)), whether it's set by the user or inherited. I can't remember if I had a good reason to put the inherit in ndo_init.
On Wed, 14 Jun 2023 14:26:14 +0200 Sabrina Dubroca wrote: > > What prevents the device from being opened and used before > > macsec_add_dev() has finished? I think we need a fix which > > would move this code before register_netdev(), instead :( > > Can the device be opened in parallel? We're under rtnl here. > > If we want to move that code, then we'll also have to move the > eth_hw_addr_inherit call that's currently in macsec's ndo_init: in > case the user didn't give an SCI, we have to make it up based on the > device's mac address (dev_to_sci(dev, ...)), whether it's set by the > user or inherited. I can't remember if I had a good reason to put the > inherit in ndo_init. Ah, you're right, this is a link creation path.
On Wed, Jun 14, 2023 at 09:01:26AM -0700, Jakub Kicinski wrote: > On Wed, 14 Jun 2023 14:26:14 +0200 Sabrina Dubroca wrote: > > > What prevents the device from being opened and used before > > > macsec_add_dev() has finished? I think we need a fix which > > > would move this code before register_netdev(), instead :( > > > > Can the device be opened in parallel? We're under rtnl here. > > > > If we want to move that code, then we'll also have to move the > > eth_hw_addr_inherit call that's currently in macsec's ndo_init: in > > case the user didn't give an SCI, we have to make it up based on the > > device's mac address (dev_to_sci(dev, ...)), whether it's set by the > > user or inherited. I can't remember if I had a good reason to put the > > inherit in ndo_init. > > Ah, you're right, this is a link creation path. My reply probably won't give any new information now but if the code of macsec_add_dev() and the parts from ndo_init it depends on which Sabrina mentioned would be moved before registering netdev then the problem will go away on its own. Is it worth moving that code if rtnl_lock is held? Maybe it will be more persistent to initialize the device for as maximum as possible before calling register_netdevice()? Overall, it all depends on the reasons why the code was implemented so initially.
2023-06-14, 23:17:14 +0300, Fedor Pchelkin wrote: > On Wed, Jun 14, 2023 at 09:01:26AM -0700, Jakub Kicinski wrote: > > On Wed, 14 Jun 2023 14:26:14 +0200 Sabrina Dubroca wrote: > > > > What prevents the device from being opened and used before > > > > macsec_add_dev() has finished? I think we need a fix which > > > > would move this code before register_netdev(), instead :( > > > > > > Can the device be opened in parallel? We're under rtnl here. > > > > > > If we want to move that code, then we'll also have to move the > > > eth_hw_addr_inherit call that's currently in macsec's ndo_init: in > > > case the user didn't give an SCI, we have to make it up based on the > > > device's mac address (dev_to_sci(dev, ...)), whether it's set by the > > > user or inherited. I can't remember if I had a good reason to put the > > > inherit in ndo_init. > > > > Ah, you're right, this is a link creation path. > > My reply probably won't give any new information now but if the code of > macsec_add_dev() and the parts from ndo_init it depends on which Sabrina > mentioned would be moved before registering netdev then the problem will > go away on its own. > > Is it worth moving that code if rtnl_lock is held? Maybe it will be more > persistent to initialize the device for as maximum as possible before > calling register_netdevice()? Overall, it all depends on the reasons why > the code was implemented so initially. It's been 7 years... your guess is about as good as mine :/ I wouldn't bother reshuffling the device creation code just to make the handling of rare failures a bit nicer.
On Wed, 14 Jun 2023 23:15:03 +0200 Sabrina Dubroca wrote: > It's been 7 years... your guess is about as good as mine :/ > > I wouldn't bother reshuffling the device creation code just to make > the handling of rare failures a bit nicer. Would you be willing to venture a review tag?
2023-06-14, 23:02:39 -0700, Jakub Kicinski wrote: > On Wed, 14 Jun 2023 23:15:03 +0200 Sabrina Dubroca wrote: > > It's been 7 years... your guess is about as good as mine :/ > > > > I wouldn't bother reshuffling the device creation code just to make > > the handling of rare failures a bit nicer. > > Would you be willing to venture a review tag? Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Hello: This patch was applied to netdev/net.git (main) by David S. Miller <davem@davemloft.net>: On Tue, 13 Jun 2023 22:22:20 +0300 you wrote: > Inside macsec_add_dev() we free percpu macsec->secy.tx_sc.stats and > macsec->stats on some of the memory allocation failure paths. However, the > net_device is already registered to that moment: in macsec_newlink(), just > before calling macsec_add_dev(). This means that during unregister process > its priv_destructor - macsec_free_netdev() - will be called and will free > the stats again. > > [...] Here is the summary with links: - net: macsec: fix double free of percpu stats https://git.kernel.org/netdev/net/c/0c0cf3db83f8 You are awesome, thank you!
diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index 3427993f94f7..984dfa5d6c11 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -3997,17 +3997,15 @@ static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len) return -ENOMEM; secy->tx_sc.stats = netdev_alloc_pcpu_stats(struct pcpu_tx_sc_stats); - if (!secy->tx_sc.stats) { - free_percpu(macsec->stats); + if (!secy->tx_sc.stats) return -ENOMEM; - } secy->tx_sc.md_dst = metadata_dst_alloc(0, METADATA_MACSEC, GFP_KERNEL); - if (!secy->tx_sc.md_dst) { - free_percpu(secy->tx_sc.stats); - free_percpu(macsec->stats); + if (!secy->tx_sc.md_dst) + /* macsec and secy percpu stats will be freed when unregistering + * net_device in macsec_free_netdev() + */ return -ENOMEM; - } if (sci == MACSEC_UNDEF_SCI) sci = dev_to_sci(dev, MACSEC_PORT_ES);
Inside macsec_add_dev() we free percpu macsec->secy.tx_sc.stats and macsec->stats on some of the memory allocation failure paths. However, the net_device is already registered to that moment: in macsec_newlink(), just before calling macsec_add_dev(). This means that during unregister process its priv_destructor - macsec_free_netdev() - will be called and will free the stats again. Remove freeing percpu stats inside macsec_add_dev() because macsec_free_netdev() will correctly free the already allocated ones. The pointers to unallocated stats stay NULL, and free_percpu() treats that correctly. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 0a28bfd4971f ("net/macsec: Add MACsec skb_metadata_dst Tx Data path support") Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> --- drivers/net/macsec.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)