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]
Date:   Tue, 12 Apr 2022 17:57:03 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: What is the purpose of dev->gflags?


Le 11/04/2022 à 18:50, Vladimir Oltean a écrit :
> On Mon, Apr 11, 2022 at 06:27:54PM +0200, Nicolas Dichtel wrote:
>> Same here. Some complex path are called (eg. dev_change_rx_flags =>
>> ops->ndo_change_rx_flags() => vlan_dev_change_rx_flags => dev_set_allmulti =>
>> __dev_set_allmulti => etc).
>> Maybe you made an audit to check that other flags cannot be changed. But, if it
>> changes in the future, we will miss them here.
> 
> I guess I just don't see what other dev->flags that aren't masked out
> from netdev notifier calls may or should change during the call to
> __dev_set_allmulti(), regardless of the complexity or depth of the
> call path.
> 
> And the commit that added the __dev_notify_flags() call said "dev:
> always advertise rx_flags changes via netlink" (i.e. the function was
> called for its rtmsg_ifinfo() part, not for its call_netdevice_notifiers()
> part).
> 
> There *was* no call to dev_notify_flags prior to that commit, and it
> didn't give a reason for voluntarily going through the netdev notifiers,
> either.
Yes.

> 
>> Did you see a bug? What is the issue?
> 
> I didn't see any bug, as mentioned I was trying to follow how
> dev->gflags is used (see title) and stumbled upon this strange pattern
> while doing so. dev->gflags is not updated from dev_set_allmulti()
> almost by definition, otherwise in-kernel drivers wouldn't have a way to
> update IFF_ALLMULTI without user space becoming aware of it.
FWIW, here is the patch that has introduced the gflags field:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/netdev-vger-cvs.git/commit/?id=c7a329628f395

> 
> The reason for emailing you to was to understand the intention, I do
> understand that the code has went through changes since 2013 and that
> a more in-depth audit is still needed before making any change.
Yep, because notifiers are called since this patch and maybe some modules expect
this now.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ