linux-stable.git/net/core/rtnetlink.c, branch v3.18.78

rtnetlink: allocate more memory for dev_set_mac_address()

2017-08-11T16:30:14+00:00

[ Upstream commit 153711f9421be5dbc973dc57a4109dc9d54c89b1 ]

virtnet_set_mac_address() interprets mac address as struct
sockaddr, but upper layer only allocates dev->addr_len
which is ETH_ALEN + sizeof(sa_family_t) in this case.

We lack a unified definition for mac address, so just fix
the upper layer, this also allows drivers to interpret it
to struct sockaddr freely.

Reported-by: David Ahern 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: fix infoleak in rtnetlink

2016-07-12T12:48:14+00:00

[ Upstream commit 5f8e44741f9f216e33736ea4ec65ca9ac03036e6 ]

The stack object “map” has a total size of 32 bytes. Its last 4
bytes are padding generated by compiler. These padding bytes are
not initialized and sent out via “nla_put”.

Signed-off-by: Kangjie Lu 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

2015-10-27T13:32:53+00:00

[ Upstream commit 4f7d2cdfdde71ffe962399b7020c674050329423 ]

Jason Gunthorpe reported that since commit c02db8c6290b ("rtnetlink: make
SR-IOV VF interface symmetric"), we don't verify IFLA_VF_INFO attributes
anymore with respect to their policy, that is, ifla_vfinfo_policy[].

Before, they were part of ifla_policy[], but they have been nested since
placed under IFLA_VFINFO_LIST, that contains the attribute IFLA_VF_INFO,
which is another nested attribute for the actual VF attributes such as
IFLA_VF_MAC, IFLA_VF_VLAN, etc.

Despite the policy being split out from ifla_policy[] in this commit,
it's never applied anywhere. nla_for_each_nested() only does basic nla_ok()
testing for struct nlattr, but it doesn't know about the data context and
their requirements.

Fix, on top of Jason's initial work, does 1) parsing of the attributes
with the right policy, and 2) using the resulting parsed attribute table
from 1) instead of the nla_for_each_nested() loop (just like we used to
do when still part of ifla_policy[]).

Reference: http://thread.gmane.org/gmane.linux.network/368913
Fixes: c02db8c6290b ("rtnetlink: make SR-IOV VF interface symmetric")
Reported-by: Jason Gunthorpe 
Cc: Chris Wright 
Cc: Sucheta Chakraborty 
Cc: Greg Rose 
Cc: Jeff Kirsher 
Cc: Rony Efraim 
Cc: Vlad Zolotarov 
Cc: Nicolas Dichtel 
Cc: Thomas Graf 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Daniel Borkmann 
Acked-by: Vlad Zolotarov 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

if_link: Add an additional parameter to ifla_vf_info for RSS querying

2015-10-27T13:31:42+00:00

[ Upstream commit 01a3d796813d6302af9f828f34b73d21a4b96c9a ]

Add configuration setting for drivers to allow/block an RSS Redirection
Table and a Hash Key querying for discrete VFs.

On some devices VF share the mentioned above information with PF and
querying it may adduce a theoretical security risk. We want to let a
system administrator to decide if he/she wants to take this risk or not.

Signed-off-by: Vlad Zolotarov 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin

rtnl: restore notifications for deleted interfaces

2015-07-21T01:12:45+00:00

The commit 984ff7a3e060 is an upstream backport. In fact, it depends on
commit 395eea6ccf2b ("rtnetlink: delay RTM_DELLINK notification until after ndo_uninit()")
which has not been backported in 3.18.y.

Before commit 395eea6ccf2b, rollback_registered_many() uses rtmsg_ifinfo().
The call to this function is done with dev->reg_state set to
NETREG_UNREGISTERING, thus testing this reg_state in rtmsg_ifinfo() is
wrong.

This patch partially reverts commit 984ff7a3e060.

Fixes: 984ff7a3e060 ("rtnl/bond: don't send rtnl msg for unregistered iface")
Reported-by: Kristian Evensen 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: Sasha Levin

rtnl/bond: don't send rtnl msg for unregistered iface

2015-06-15T18:26:49+00:00

[ Upstream commit ed2a80ab7b76f11af0b2c6255709c4ebf164b667 ]

Before the patch, the command 'ip link add bond2 type bond mode 802.3ad'
causes the kernel to send a rtnl message for the bond2 interface, with an
ifindex 0.

'ip monitor' shows:
0: bond2:  mtu 1500 state DOWN group default
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
9: bond2@NONE:  mtu 1500 qdisc noop state DOWN group default
    link/ether ea:3e:1f:53:92:7b brd ff:ff:ff:ff:ff:ff
[snip]

The patch fixes the spotted bug by checking in bond driver if the interface
is registered before calling the notifier chain.
It also adds a check in rtmsg_ifinfo() to prevent this kind of bug in the
future.

Fixes: d4261e565000 ("bonding: create netlink event when bonding option is changed")
CC: Jiri Pirko 
Reported-by: Julien Meunier 
Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: do not use rcu in rtnl_dump_ifinfo()

2015-03-14T19:37:13+00:00

[ Upstream commit cac5e65e8a7ea074f2626d2eaa53aa308452dec4 ]

We did a failed attempt in the past to only use rcu in rtnl dump
operations (commit e67f88dd12f6 "net: dont hold rtnl mutex during
netlink dump callbacks")

Now that dumps are holding RTNL anyway, there is no need to also
use rcu locking, as it forbids any scheduling ability, like
GFP_KERNEL allocations that controlling path should use instead
of GFP_ATOMIC whenever possible.

This should fix following splat Cong Wang reported :

 [ INFO: suspicious RCU usage. ]
 3.19.0+ #805 Tainted: G        W

 include/linux/rcupdate.h:538 Illegal context switch in RCU read-side critical section!

 other info that might help us debug this:

 rcu_scheduler_active = 1, debug_locks = 0
 2 locks held by ip/771:
  #0:  (rtnl_mutex){+.+.+.}, at: [] netlink_dump+0x21/0x26c
  #1:  (rcu_read_lock){......}, at: [] rcu_read_lock+0x0/0x6e

 stack backtrace:
 CPU: 3 PID: 771 Comm: ip Tainted: G        W       3.19.0+ #805
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  0000000000000001 ffff8800d51e7718 ffffffff81a27457 0000000029e729e6
  ffff8800d6108000 ffff8800d51e7748 ffffffff810b539b ffffffff820013dd
  00000000000001c8 0000000000000000 ffff8800d7448088 ffff8800d51e7758
 Call Trace:
  [] dump_stack+0x4c/0x65
  [] lockdep_rcu_suspicious+0x107/0x110
  [] rcu_preempt_sleep_check+0x45/0x47
  [] ___might_sleep+0x1d/0x1cb
  [] __might_sleep+0x78/0x80
  [] idr_alloc+0x45/0xd1
  [] ? rcu_read_lock_held+0x3b/0x3d
  [] ? idr_for_each+0x53/0x101
  [] alloc_netid+0x61/0x69
  [] __peernet2id+0x79/0x8d
  [] peernet2id+0x13/0x1f
  [] rtnl_fill_ifinfo+0xa8d/0xc20
  [] ? __lock_is_held+0x39/0x52
  [] rtnl_dump_ifinfo+0x149/0x213
  [] netlink_dump+0xef/0x26c
  [] netlink_recvmsg+0x17b/0x2c5
  [] __sock_recvmsg+0x4e/0x59
  [] sock_recvmsg+0x3f/0x51
  [] ___sys_recvmsg+0xf6/0x1d9
  [] ? handle_pte_fault+0x6e1/0xd3d
  [] ? native_sched_clock+0x35/0x37
  [] ? sched_clock_local+0x12/0x72
  [] ? sched_clock_cpu+0x9e/0xb7
  [] ? rcu_read_lock_held+0x3b/0x3d
  [] ? __fcheck_files+0x4c/0x58
  [] ? __fget_light+0x2d/0x52
  [] __sys_recvmsg+0x42/0x60
  [] SyS_recvmsg+0x12/0x1c

Signed-off-by: Eric Dumazet 
Fixes: 0c7aecd4bde4b7302 ("netns: add rtnl cmd to add and get peer netns ids")
Cc: Nicolas Dichtel 
Reported-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

rtnetlink: call ->dellink on failure when ->newlink exists

2015-03-14T19:37:10+00:00

[ Upstream commit 7afb8886a05be68e376655539a064ec672de8a8e ]

Ignacy reported that when eth0 is down and add a vlan device
on top of it like:

  ip link add link eth0 name eth0.1 up type vlan id 1

We will get a refcount leak:

  unregister_netdevice: waiting for eth0.1 to become free. Usage count = 2

The problem is when rtnl_configure_link() fails in rtnl_newlink(),
we simply call unregister_device(), but for stacked device like vlan,
we almost do nothing when we unregister the upper device, more work
is done when we unregister the lower device, so call its ->dellink().

Reported-by: Ignacy Gawedzki 
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY

2015-03-14T19:37:09+00:00

[ Upstream commit 364d5716a7adb91b731a35765d369602d68d2881 ]

ifla_vf_policy[] is wrong in advertising its individual member types as
NLA_BINARY since .type = NLA_BINARY in combination with .len declares the
len member as *max* attribute length [0, len].

The issue is that when do_setvfinfo() is being called to set up a VF
through ndo handler, we could set corrupted data if the attribute length
is less than the size of the related structure itself.

The intent is exactly the opposite, namely to make sure to pass at least
data of minimum size of len.

Fixes: ebc08a6f47ee ("rtnetlink: Add VF config code to rtnetlink")
Cc: Mitch Williams 
Cc: Jeff Kirsher 
Signed-off-by: Daniel Borkmann 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

bridge: dont send notification when skb->len == 0 in rtnl_bridge_notify

2015-02-27T01:49:01+00:00

[ Upstream commit 59ccaaaa49b5b096cdc1f16706a9f931416b2332 ]

Reported in: https://bugzilla.kernel.org/show_bug.cgi?id=92081

This patch avoids calling rtnl_notify if the device ndo_bridge_getlink
handler does not return any bytes in the skb.

Alternately, the skb->len check can be moved inside rtnl_notify.

For the bridge vlan case described in 92081, there is also a fix needed
in bridge driver to generate a proper notification. Will fix that in
subsequent patch.

v2: rebase patch on net tree

Signed-off-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman