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

rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

2015-08-12T14:33:20+00:00

commit 4f7d2cdfdde71ffe962399b7020c674050329423 upstream.

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 
[bwh: Backported to 3.2:
 - Drop unsupported attributes
 - Use ndo_set_vf_tx_rate operation, not ndo_set_vf_rate]
Signed-off-by: Ben Hutchings

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

2015-05-09T22:16:37+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: Ben Hutchings

net: use for_each_netdev_safe() in rtnl_group_changelink()

2015-05-09T22:16:32+00:00

commit d079535d5e1bf5e2e7c856bae2483414ea21e137 upstream.

In case we move the whole dev group to another netns,
we should call for_each_netdev_safe(), otherwise we get
a soft lockup:

 NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ip:798]
 irq event stamp: 255424
 hardirqs last  enabled at (255423): [] restore_args+0x0/0x30
 hardirqs last disabled at (255424): [] apic_timer_interrupt+0x6a/0x80
 softirqs last  enabled at (255422): [] __do_softirq+0x2c1/0x3a9
 softirqs last disabled at (255417): [] irq_exit+0x41/0x95
 CPU: 0 PID: 798 Comm: ip Not tainted 4.0.0-rc4+ #881
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 task: ffff8800d1b88000 ti: ffff880119530000 task.ti: ffff880119530000
 RIP: 0010:[]  [] debug_lockdep_rcu_enabled+0x28/0x30
 RSP: 0018:ffff880119533778  EFLAGS: 00000246
 RAX: ffff8800d1b88000 RBX: 0000000000000002 RCX: 0000000000000038
 RDX: 0000000000000000 RSI: ffff8800d1b888c8 RDI: ffff8800d1b888c8
 RBP: ffff880119533778 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 000000000000b5c2 R12: 0000000000000246
 R13: ffff880119533708 R14: 00000000001d5a40 R15: ffff88011a7d5a40
 FS:  00007fc01315f740(0000) GS:ffff88011a600000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 00007f367a120988 CR3: 000000011849c000 CR4: 00000000000007f0
 Stack:
  ffff880119533798 ffffffff811ac868 ffffffff811ac831 ffffffff811ac828
  ffff8801195337c8 ffffffff811ac8c9 ffff8801195339b0 ffff8801197633e0
  0000000000000000 ffff8801195339b0 ffff8801195337d8 ffffffff811ad2d7
 Call Trace:
  [] rcu_read_lock+0x37/0x6e
  [] ? rcu_read_unlock+0x5f/0x5f
  [] ? rcu_read_unlock+0x56/0x5f
  [] __fget+0x2a/0x7a
  [] fget+0x13/0x15
  [] proc_ns_fget+0xe/0x38
  [] get_net_ns_by_fd+0x11/0x59
  [] rtnl_link_get_net+0x33/0x3e
  [] do_setlink+0x73/0x87b
  [] ? trace_hardirqs_off+0xd/0xf
  [] ? retint_restore_args+0xe/0xe
  [] rtnl_newlink+0x40c/0x699
  [] ? rtnl_newlink+0xeb/0x699
  [] ? _raw_spin_unlock+0x28/0x33
  [] ? security_capable+0x18/0x1a
  [] ? ns_capable+0x4d/0x65
  [] rtnetlink_rcv_msg+0x181/0x194
  [] ? rtnl_lock+0x17/0x19
  [] ? rtnl_lock+0x17/0x19
  [] ? __rtnl_unlock+0x17/0x17
  [] netlink_rcv_skb+0x4d/0x93
  [] rtnetlink_rcv+0x26/0x2d
  [] netlink_unicast+0xcb/0x150
  [] netlink_sendmsg+0x501/0x523
  [] ? might_fault+0x59/0xa9
  [] ? copy_from_user+0x2a/0x2c
  [] sock_sendmsg+0x34/0x3c
  [] ___sys_sendmsg+0x1b8/0x255
  [] ? handle_pte_fault+0xbd5/0xd4a
  [] ? 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_sendmsg+0x42/0x60
  [] SyS_sendmsg+0x12/0x1c
  [] system_call_fastpath+0x12/0x17

Fixes: e7ed828f10bd8 ("netlink: support setting devgroup parameters")
Signed-off-by: Cong Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rtnetlink: ifla_vf_policy: fix misuses of NLA_BINARY

2015-05-09T22:16:15+00:00

commit 364d5716a7adb91b731a35765d369602d68d2881 upstream.

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 
[bwh: Backported to 3.2: drop the unsupported attributes]
Signed-off-by: Ben Hutchings

rtnetlink: fix userspace API breakage for iproute2 < v3.9.0

2014-08-06T17:07:39+00:00

commit e5eca6d41f53db48edd8cf88a3f59d2c30227f8e upstream.

When running RHEL6 userspace on a current upstream kernel, "ip link"
fails to show VF information.

The reason is a kernel<->userspace API change introduced by commit
88c5b5ce5cb57 ("rtnetlink: Call nlmsg_parse() with correct header length"),
after which the kernel does not see iproute2's IFLA_EXT_MASK attribute
in the netlink request.

iproute2 adjusted for the API change in its commit 63338dca4513
("libnetlink: Use ifinfomsg instead of rtgenmsg in rtnl_wilddump_req_filter").

The problem has been noticed before:
http://marc.info/?l=linux-netdev&m=136692296022182&w=2
(Subject: Re: getting VF link info seems to be broken in 3.9-rc8)

We can do better than tell those with old userspace to upgrade. We can
recognize the old iproute2 in the kernel by checking the netlink message
length. Even when including the IFLA_EXT_MASK attribute, its netlink
message is shorter than struct ifinfomsg.

With this patch "ip link" shows VF information in both old and new
iproute2 versions.

Signed-off-by: Michal Schmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rtnetlink: Only supply IFLA_VF_PORTS information when RTEXT_FILTER_VF is set

2014-06-09T12:28:57+00:00

[ Upstream commit c53864fd60227de025cb79e05493b13f69843971 ]

Since 115c9b81928360d769a76c632bae62d15206a94a (rtnetlink: Fix problem with
buffer allocation), RTM_NEWLINK messages only contain the IFLA_VFINFO_LIST
attribute if they were solicited by a GETLINK message containing an
IFLA_EXT_MASK attribute with the RTEXT_FILTER_VF flag.

That was done because some user programs broke when they received more data
than expected - because IFLA_VFINFO_LIST contains information for each VF
it can become large if there are many VFs.

However, the IFLA_VF_PORTS attribute, supplied for devices which implement
ndo_get_vf_port (currently the 'enic' driver only), has the same problem.
It supplies per-VF information and can therefore become large, but it is
not currently conditional on the IFLA_EXT_MASK value.

Worse, it interacts badly with the existing EXT_MASK handling.  When
IFLA_EXT_MASK is not supplied, the buffer for netlink replies is fixed at
NLMSG_GOODSIZE.  If the information for IFLA_VF_PORTS exceeds this, then
rtnl_fill_ifinfo() returns -EMSGSIZE on the first message in a packet.
netlink_dump() will misinterpret this as having finished the listing and
omit data for this interface and all subsequent ones.  That can cause
getifaddrs(3) to enter an infinite loop.

This patch addresses the problem by only supplying IFLA_VF_PORTS when
IFLA_EXT_MASK is supplied with the RTEXT_FILTER_VF flag set.

Signed-off-by: David Gibson 
Reviewed-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rtnetlink: Warn when interface's information won't fit in our packet

2014-06-09T12:28:57+00:00

[ Upstream commit 973462bbde79bb827824c73b59027a0aed5c9ca6 ]

Without IFLA_EXT_MASK specified, the information reported for a single
interface in response to RTM_GETLINK is expected to fit within a netlink
packet of NLMSG_GOODSIZE.

If it doesn't, however, things will go badly wrong,  When listing all
interfaces, netlink_dump() will incorrectly treat -EMSGSIZE on the first
message in a packet as the end of the listing and omit information for
that interface and all subsequent ones.  This can cause getifaddrs(3) to
enter an infinite loop.

This patch won't fix the problem, but it will WARN_ON() making it easier to
track down what's going wrong.

Signed-off-by: David Gibson 
Reviewed-by: Jiri Pirko 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rtnetlink: Call nlmsg_parse() with correct header length

2013-05-13T14:02:37+00:00

[ Upstream commit 88c5b5ce5cb57af6ca2a7cf4d5715fa320448ff9 ]

Signed-off-by: Michael Riesch 
Cc: "David S. Miller" 
Cc: Greg Kroah-Hartman 
Cc: Jiri Benc 
Cc: "Theodore Ts'o" 
Cc: linux-kernel@vger.kernel.org
Acked-by: Mark Rustad 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rtnetlink: Mask the rta_type when range checking

2013-03-27T02:41:07+00:00

[ Upstream commit a5b8db91442fce9c9713fcd656c3698f1adde1d6 ]

Range/validity checks on rta_type in rtnetlink_rcv_msg() do
not account for flags that may be set.  This causes the function
to return -EINVAL when flags are set on the type (for example
NLA_F_NESTED).

Signed-off-by: Vlad Yasevich 
Acked-by: Thomas Graf 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings

rtnl: fix info leak on RTM_GETLINK request for VF devices

2013-03-27T02:40:58+00:00

[ Upstream commit 84d73cd3fb142bf1298a8c13fd4ca50fd2432372 ]

Initialize the mac address buffer with 0 as the driver specific function
will probably not fill the whole buffer. In fact, all in-kernel drivers
fill only ETH_ALEN of the MAX_ADDR_LEN bytes, i.e. 6 of the 32 possible
bytes. Therefore we currently leak 26 bytes of stack memory to userland
via the netlink interface.

Signed-off-by: Mathias Krause 
Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings