netdev - Re: [PATCH v2 net] ipvlan: do not add hardware address of master to its unicast filter list

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: <20200308.211428.244940116218476313.davem@davemloft.net>
Date:   Sun, 08 Mar 2020 21:14:28 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     jwiesner@...e.com
Cc:     netdev@...r.kernel.org, maheshb@...gle.com,
        Andreas.Taschner@...e.com, mkubecek@...e.cz
Subject: Re: [PATCH v2 net] ipvlan: do not add hardware address of master
 to its unicast filter list

From: Jiri Wiesner <jwiesner@...e.com>
Date: Sat, 7 Mar 2020 13:31:57 +0100

> There is a problem when ipvlan slaves are created on a master device that
> is a vmxnet3 device (ipvlan in VMware guests). The vmxnet3 driver does not
> support unicast address filtering. When an ipvlan device is brought up in
> ipvlan_open(), the ipvlan driver calls dev_uc_add() to add the hardware
> address of the vmxnet3 master device to the unicast address list of the
> master device, phy_dev->uc. This inevitably leads to the vmxnet3 master
> device being forced into promiscuous mode by __dev_set_rx_mode().
> 
> Promiscuous mode is switched on the master despite the fact that there is
> still only one hardware address that the master device should use for
> filtering in order for the ipvlan device to be able to receive packets.
> The comment above struct net_device describes the uc_promisc member as a
> "counter, that indicates, that promiscuous mode has been enabled due to
> the need to listen to additional unicast addresses in a device that does
> not implement ndo_set_rx_mode()". Moreover, the design of ipvlan
> guarantees that only the hardware address of a master device,
> phy_dev->dev_addr, will be used to transmit and receive all packets from
> its ipvlan slaves. Thus, the unicast address list of the master device
> should not be modified by ipvlan_open() and ipvlan_stop() in order to make
> ipvlan a workable option on masters that do not support unicast address
> filtering.
> 
> Fixes: 2ad7bf3638411 ("ipvlan: Initial check-in of the IPVLAN driver")
> Reported-by: Per Sundstrom <per.sundstrom@...qube.se>
> Signed-off-by: Jiri Wiesner <jwiesner@...e.com>
> Reviewed-by: Eric Dumazet <edumazet@...gle.com>
> Acked-by: Mahesh Bandewar <maheshb@...gle.com>

Applied and queued up for -stable, thank you.