netdev - Re: [PATCH net v3] net: atm: Fix incorrect net

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: <20250707163056.GO89747@horms.kernel.org>
Date: Mon, 7 Jul 2025 17:30:56 +0100
From: Simon Horman <horms@...nel.org>
To: Lin Ma <linma@....edu.cn>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, mingo@...nel.org, tglx@...utronix.de,
	pwn9uin@...il.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v3] net: atm: Fix incorrect net_device lec check

On Sat, Jul 05, 2025 at 11:04:02AM +0800, Lin Ma wrote:
> Hi Simon,
> 
> > Can start_mpc() run on dev before this function is called?
> > If so, does the check above still work as expected?
> 
> Great point. I found two locatinos that call start_mpc(). One
> is atm_mpoa_mpoad_attach() and the other is mpoa_event_listener().
> 
> Since this patch covers these two functions, I believe start_mpc()
> run after the check.
> 
> However, since start_mpc() indeed replaces the netdev_ops. It seems
> quite error-prone to perform type checking using that field. Moreover,
> this patch raises a linking error as shown in
> https://lore.kernel.org/oe-kbuild-all/202507050831.2GTrUnFN-lkp@intel.com/.
> Hence, I will prepare version 4 and try to think about other solutions.

Thanks. I was thinking along the same lines.

> 
> >
> > 1) Is this code path reachable by non-lec devices?
> >
> 
> Yes, though the mpoa_event_listener() is registered for the net/mpc module,
> the notifier_block calls every registered listener.
> 
> /** ....
>  *  Calls each function in a notifier chain in turn.  The functions
>  *  run in an undefined context.
>  *  All locking must be provided by the caller.
>  *  ...
>  */
> int raw_notifier_call_chain(struct raw_notifier_head *nh,
>         unsigned long val, void *v)
> 
> In another word, every registered listener is reachable and is responsible
> for determining whether the event is relevant to them. And that is why we
> should add a type check here.

Understood, makes sense.

> 
> > 2) Can the name of a lec device be changed?
>    If so, does it cause a problem here?
> 
> To my knowledge, the changing of a net_device name is handled in
> net/core/dev.c, which is a general functionality that an individual driver
> cannot intervene.
> 
> int __dev_change_net_namespace(struct net_device *dev, struct net *net,
>                    const char *pat, int new_ifindex)
> {
>     ...
>         if (new_name[0]) /* Rename the netdev to prepared name */
>         strscpy(dev->name, new_name, IFNAMSIZ);
>     ...
> }
> 
> Nice catch.
> If a user changes a lec device name to something else that is not
> prefixed with "lec", it causes functionality issues, as events
> like NETDEV_UP/DOWN cannot reach the inner logic.
> 
> That will be another reason to adopt a fix.

Yes, that seems likely.
But perhaps such a fix is orthogonal from the one that started this thread.