netdev - Re: [PATCH net v4 00/12] net: fix nested device bugs

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]

Date:   Sun, 29 Sep 2019 17:31:15 +0900
From:   Taehee Yoo <ap420073@...il.com>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>, linux-wireless@...r.kernel.org,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        j.vosburgh@...il.com, vfalico@...il.com,
        Andy Gospodarek <andy@...yhouse.net>,
        Jiří Pírko <jiri@...nulli.us>,
        sd@...asysnail.net, Roopa Prabhu <roopa@...ulusnetworks.com>,
        saeedm@...lanox.com, manishc@...vell.com, rahulv@...vell.com,
        kys@...rosoft.com, haiyangz@...rosoft.com,
        Stephen Hemminger <stephen@...workplumber.org>,
        sashal@...nel.org, hare@...e.de, varun@...lsio.com,
        ubraun@...ux.ibm.com, kgraul@...ux.ibm.com,
        Jay Vosburgh <jay.vosburgh@...onical.com>,
        Cody Schuffelen <schuffelen@...gle.com>, bjorn@...k.no
Subject: Re: [PATCH net v4 00/12] net: fix nested device bugs

On Sun, 29 Sep 2019 at 04:20, Johannes Berg <johannes@...solutions.net> wrote:
>
>
> > VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI and VXLAN.
> > But I couldn't test all interface types so there could be more device
> > types which have similar problems.
>
> Did you test virt_wifi? I don't see how it *doesn't* have the nesting
> problem, and you didn't change it?
>
> No, I see. You're limiting the nesting generally now in patch 1, and the
> others are just lockdep fixups (I guess it's surprising virt_wifi
> doesn't do this at all?).

virt_wifi case is a little bit different case.
I add the last patch that is to fix refcnt leaks in the virt_wifi module.
The way to fix this is to add notifier routine.
The notifier routine could delete lower device before deleting
virt_wifi device.
If virt_wifi devices are nested, notifier would work recursively.
At that time, it would make stack memory overflow.

Actually, before this patch, virt_wifi doesn't have the same problem.
So, I will update a comment in a v5 patch.

>
> FWIW I don't think virt_wifi really benefits at all from stacking, so we
> could just do something like
>
> --- a/drivers/net/wireless/virt_wifi.c
> +++ b/drivers/net/wireless/virt_wifi.c
> @@ -508,6 +508,9 @@ static int virt_wifi_newlink(struct net *src_net, struct net_device *dev,
>         else if (dev->mtu > priv->lowerdev->mtu)
>                 return -EINVAL;
>
> +       if (priv->lowerdev->ieee80211_ptr)
> +               return -EINVAL;
> +
>         err = netdev_rx_handler_register(priv->lowerdev, virt_wifi_rx_handler,
>                                          priv);
>         if (err) {
>

Many other devices use this way to avoid wrong nesting configuration.
And I think it's a good way.
But we should think about the below configuration.

vlan5
   |
virt_wifi4
   |
vlan3
   |
virt_wifi2
   |
vlan1
   |
dummy0

That code wouldn't avoid this configuration.
And all devices couldn't avoid this config.
I have been considering this case, but I couldn't make a decision yet.
Maybe common netdev function is needed to find the same device type
 in their graph.

>
>
> IMHO, but of course generally limiting the stack depth is needed anyway
> and solves the problem well enough for virt_wifi.
>
>

This is a little bit different question for you.
I found another bug in virt_wifi after my last patch.
Please test below commands
    ip link add dummy0 type dummy
    ip link add vw1 link dummy0 type virt_wifi
    ip link add vw2 link vw1 type virt_wifi
    modprobe -rv virt_wifi

Then, you can see the warning messages.
If SET_NETDEV_DEV() is deleted in the virt_wifi_newlink(),
you can avoid that warning message.
But I'm not sure about it's safe to remove that.
I would really appreciate it if you let me know about that.

> johannes
>