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  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:   Mon, 18 May 2020 12:14:28 -0700
From:   Cong Wang <>
To:     Michał Mirosław <>
Cc:     Jarod Wilson <>,
        Linux Kernel Network Developers <>
Subject: Re: net: netdev_sync_lower_features()

On Mon, May 18, 2020 at 1:32 AM Michał Mirosław <> wrote:
> Hi!
> I just saw commit dd912306ff008 ("net: fix a potential recursive
> NETDEV_FEAT_CHANGE") landing in Linux master. The problem with it (or
> rather: with the netdev_sync_lower_features() function) is that
> netdev_update_features() is allowed to change more than one feature
> at a time, including force-enabling other feature than one that is
> being disabled. I think that a better fix would be to trigger
> notification only after all features are updated (outside of the loop).

Sounds reasonable. But I don't think this problem is introduced by
my commit, my commit merely skips the notification for the

> When you consider net effect of the function, the loop's added value
> is only to print debug messages. Other than that it's equivalent to:
> lower->wanted_features &= ~upper_disables;
> netdev_update_features(lower);
> The problem of spurious notification can be fixed in
> __netdev_update_features() by saving dev->features at the start and
> only return -1 when it really changed.

Please send a patch.


Powered by blists - more mailing lists