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: <5c66d883.a83f.197d88a76c4.Coremail.linma@zju.edu.cn>
Date: Sat, 5 Jul 2025 11:04:02 +0800 (GMT+08:00)
From: "Lin Ma" <linma@....edu.cn>
To: "Simon Horman" <horms@...nel.org>
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

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.

>
> 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.

> 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.

Regards
Lin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ