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

Powered by blists - more mailing lists