netdev - Re: [PATCH net 1/2] net: ethernet: ftgmac100: prevent use after free on unregister when using NCSI

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] [day] [month] [year] [list]

Message-ID: <7e798de6-0476-4d1b-922b-51c335d6d0b1@mendozajonas.com>
Date: Wed, 30 Oct 2024 20:02:39 +1100
From: Sam Mendoza-Jonas <sam@...dozajonas.com>
To: Jeremy Kerr <jk@...econstruct.com.au>, Jakub Kicinski <kuba@...nel.org>
Cc: Andrew Lunn <andrew@...n.ch>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, Joel Stanley <joel@....id.au>,
 Jacky Chou <jacky_chou@...eedtech.com>,
 Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net 1/2] net: ethernet: ftgmac100: prevent use after free
 on unregister when using NCSI

On 10/30/2024 1:58 PM, Jeremy Kerr wrote:
> Hi all,
>
> [+Sam, as ncsi maintainer]
>
>> So, this worth a try with the _remove sequence reordered with respect
>> to the ncsi device. I'll work on a replacement patch to see if that
>> can be done without other fallout, and will send a follow-up soon.
> OK, not so simple. ftgmac100_probe does a:
>    
>      ncsi_register_dev()
>        -> dev_add_pack()
>      register_netdev()
>
> - where ptype.dev is the ftgmac netdev.
>
> So we'd want to restructure the _remove to do:
>
>      unregister_netdev()
>      ncsi_unregister_dev()
>       -> dev_remove_pack()
>
> However, we (sensibly) can't do the unregister_netdev() with a
> packet-type handler still in place.
>
> Sam: would it make sense to move the dev_add_pack() / dev_remove_pack()
> to the ncsi layer's ncsi_start_dev() / ncsi_stop_dev() ? The channel
> monitor is disabled on stop, so we shouldn't expect to receive any
> further NCSI ethertype packets.

Having a quick re-read of those and ncsi_reset_dev() that looks fine on 
the surface; as you say outside of those no packet handling is happening 
and the link is forced down.

Cheers,
Sam