linux-toradex.git/net/netlink, branch v3.10.8

genetlink: fix family dump race

2013-08-20T15:43:03+00:00

commit 58ad436fcf49810aa006016107f494c9ac9013db upstream.

When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.

A similar bug was reported to me on an old kernel (3.4.47) but
the exact scenario that happened there is no longer possible,
on those kernels the first round wasn't locked either. Looking
at the current code I found the race described above, which had
also existed on the old kernel.

Reported-by: Andrei Otcheretianski 
Signed-off-by: Johannes Berg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

genetlink: release cb_lock before requesting additional module

2013-08-12T01:35:25+00:00

[ Upstream commit c74f2b2678f40b80265dd53556f1f778c8e1823f ]

Requesting external module with cb_lock taken can result in
the deadlock like showed below:

[ 2458.111347] Showing all locks held in the system:
[ 2458.111347] 1 lock held by NetworkManager/582:
[ 2458.111347]  #0:  (cb_lock){++++++}, at: [] genl_rcv+0x19/0x40
[ 2458.111347] 1 lock held by modprobe/603:
[ 2458.111347]  #0:  (cb_lock){++++++}, at: [] genl_lock_all+0x15/0x30

[ 2461.579457] SysRq : Show Blocked State
[ 2461.580103]   task                        PC stack   pid father
[ 2461.580103] NetworkManager  D ffff880034b84500  4040   582      1 0x00000080
[ 2461.580103]  ffff8800197ff720 0000000000000046 00000000001d5340 ffff8800197fffd8
[ 2461.580103]  ffff8800197fffd8 00000000001d5340 ffff880019631700 7fffffffffffffff
[ 2461.580103]  ffff8800197ff880 ffff8800197ff878 ffff880019631700 ffff880019631700
[ 2461.580103] Call Trace:
[ 2461.580103]  [] schedule+0x29/0x70
[ 2461.580103]  [] schedule_timeout+0x1c1/0x360
[ 2461.580103]  [] ? mark_held_locks+0xbb/0x140
[ 2461.580103]  [] ? _raw_spin_unlock_irq+0x2c/0x50
[ 2461.580103]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 2461.580103]  [] wait_for_completion_killable+0xe8/0x170
[ 2461.580103]  [] ? wake_up_state+0x20/0x20
[ 2461.580103]  [] call_usermodehelper_exec+0x1a5/0x210
[ 2461.580103]  [] ? wait_for_completion_killable+0x3d/0x170
[ 2461.580103]  [] __request_module+0x1b3/0x370
[ 2461.580103]  [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 2461.580103]  [] ctrl_getfamily+0x159/0x190
[ 2461.580103]  [] genl_family_rcv_msg+0x1f4/0x2e0
[ 2461.580103]  [] ? genl_family_rcv_msg+0x2e0/0x2e0
[ 2461.580103]  [] genl_rcv_msg+0x8e/0xd0
[ 2461.580103]  [] netlink_rcv_skb+0xa9/0xc0
[ 2461.580103]  [] genl_rcv+0x28/0x40
[ 2461.580103]  [] netlink_unicast+0xdd/0x190
[ 2461.580103]  [] netlink_sendmsg+0x329/0x750
[ 2461.580103]  [] sock_sendmsg+0x99/0xd0
[ 2461.580103]  [] ? local_clock+0x5f/0x70
[ 2461.580103]  [] ? lock_release_non_nested+0x308/0x350
[ 2461.580103]  [] ___sys_sendmsg+0x39e/0x3b0
[ 2461.580103]  [] ? kvm_clock_read+0x2f/0x50
[ 2461.580103]  [] ? sched_clock+0x9/0x10
[ 2461.580103]  [] ? sched_clock_local+0x1d/0x80
[ 2461.580103]  [] ? sched_clock_cpu+0xa8/0x100
[ 2461.580103]  [] ? trace_hardirqs_off+0xd/0x10
[ 2461.580103]  [] ? local_clock+0x5f/0x70
[ 2461.580103]  [] ? lock_release_holdtime.part.28+0xf/0x1a0
[ 2461.580103]  [] ? fget_light+0xf9/0x510
[ 2461.580103]  [] ? fget_light+0x3c/0x510
[ 2461.580103]  [] __sys_sendmsg+0x42/0x80
[ 2461.580103]  [] SyS_sendmsg+0x12/0x20
[ 2461.580103]  [] system_call_fastpath+0x16/0x1b
[ 2461.580103] modprobe        D ffff88000f2c8000  4632   603    602 0x00000080
[ 2461.580103]  ffff88000f04fba8 0000000000000046 00000000001d5340 ffff88000f04ffd8
[ 2461.580103]  ffff88000f04ffd8 00000000001d5340 ffff8800377d4500 ffff8800377d4500
[ 2461.580103]  ffffffff81d0b260 ffffffff81d0b268 ffffffff00000000 ffffffff81d0b2b0
[ 2461.580103] Call Trace:
[ 2461.580103]  [] schedule+0x29/0x70
[ 2461.580103]  [] rwsem_down_write_failed+0xed/0x1a0
[ 2461.580103]  [] ? update_cpu_load_active+0x10/0xb0
[ 2461.580103]  [] call_rwsem_down_write_failed+0x13/0x20
[ 2461.580103]  [] ? down_write+0x9d/0xb2
[ 2461.580103]  [] ? genl_lock_all+0x15/0x30
[ 2461.580103]  [] genl_lock_all+0x15/0x30
[ 2461.580103]  [] genl_register_family+0x53/0x1f0
[ 2461.580103]  [] ? 0xffffffffa01dbfff
[ 2461.580103]  [] genl_register_family_with_ops+0x20/0x80
[ 2461.580103]  [] ? 0xffffffffa01dbfff
[ 2461.580103]  [] nl80211_init+0x24/0xf0 [cfg80211]
[ 2461.580103]  [] ? 0xffffffffa01dbfff
[ 2461.580103]  [] cfg80211_init+0x43/0xdb [cfg80211]
[ 2461.580103]  [] do_one_initcall+0xfa/0x1b0
[ 2461.580103]  [] ? set_memory_nx+0x43/0x50
[ 2461.580103]  [] load_module+0x1c6f/0x27f0
[ 2461.580103]  [] ? store_uevent+0x40/0x40
[ 2461.580103]  [] SyS_finit_module+0x86/0xb0
[ 2461.580103]  [] system_call_fastpath+0x16/0x1b
[ 2461.580103] Sched Debug Version: v0.10, 3.11.0-0.rc1.git4.1.fc20.x86_64 #1

Problem start to happen after adding net-pf-16-proto-16-family-nl80211
alias name to cfg80211 module by below commit (though that commit
itself is perfectly fine):

commit fb4e156886ce6e8309e912d8b370d192330d19d3
Author: Marcel Holtmann 
Date:   Sun Apr 28 16:22:06 2013 -0700

    nl80211: Add generic netlink module alias for cfg80211/nl80211

Reported-and-tested-by: Jeff Layton 
Reported-by: Richard W.M. Jones 
Signed-off-by: Stanislaw Gruszka 
Reviewed-by: Pravin B Shelar 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netlink: fix error propagation in netlink_mmap()

2013-06-11T09:52:47+00:00

Return the error if something went wrong instead of unconditionally
returning 0.

Signed-off-by: Patrick McHardy 
Signed-off-by: David S. Miller

net: fix sk_buff head without data area

2013-06-05T00:26:49+00:00

Eric Dumazet spotted that we have to check skb->head instead
of skb->data as skb->head points to the beginning of the
data area of the skbuff. Similarly, we have to initialize the
skb->head pointer, not skb->data in __alloc_skb_head.

After this fix, netlink crashes in the release path of the
sk_buff, so let's fix that as well.

This bug was introduced in (0ebd0ac net: add function to
allocate sk_buff head without data area).

Reported-by: Eric Dumazet 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: David S. Miller

netlink: kconfig: move mmap i/o into netlink kconfig

2013-05-01T19:02:42+00:00

Currently, in menuconfig, Netlink's new mmaped IO is the very first
entry under the ``Networking support'' item and comes even before
``Networking options'':

  [ ]   Netlink: mmaped IO
  Networking options  --->
  ...

Lets move this into ``Networking options'' under netlink's Kconfig,
since this might be more appropriate. Introduced by commit ccdfcc398
(``netlink: mmaped netlink: ring setup'').

Signed-off-by: Daniel Borkmann 
Signed-off-by: David S. Miller

netlink: Fix skb ref counting.

2013-05-01T18:57:03+00:00

Commit f9c2288837ba072b21dba955f04a4c97eaa77b1e (netlink:
implement memory mapped recvmsg) increamented skb->users
ref count twice for a dump op which does not look right.

Following patch fixes that.

CC: Patrick McHardy 
Signed-off-by: Pravin B Shelar 
Signed-off-by: David S. Miller

genetlink: fix possible memory leak in genl_family_rcv_msg()

2013-04-27T03:25:39+00:00

'attrbuf' is malloced in genl_family_rcv_msg() when family->maxattr &&
family->parallel_ops, thus should be freed before leaving from the error
handling cases, otherwise it will cause memory leak.

Introduced by commit def3117493eafd9dfa1f809d861e0031b2cc8a07
(genl: Allow concurrent genl callbacks.)

Signed-off-by: Wei Yongjun 
Signed-off-by: David S. Miller

genl: Allow concurrent genl callbacks.

2013-04-25T05:43:15+00:00

All genl callbacks are serialized by genl-mutex. This can become
bottleneck in multi threaded case.
Following patch adds an parameter to genl_family so that a
particular family can get concurrent netlink callback without
genl_lock held.
New rw-sem is used to protect genl callback from genl family unregister.
in case of parallel_ops genl-family read-lock is taken for callbacks and
write lock is taken for register or unregistration for any family.
In case of locked genl family semaphore and gel-mutex is locked for
any openration.

Signed-off-by: Pravin B Shelar 
Signed-off-by: David S. Miller

netlink: fix compilation after memory mapped patches

2013-04-24T18:26:55+00:00

Depending of the kernel configuration (CONFIG_UIDGID_STRICT_TYPE_CHECKS), we can
get the following errors:

net/netlink/af_netlink.c: In function ‘netlink_queue_mmaped_skb’:
net/netlink/af_netlink.c:663:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kuid_t’
net/netlink/af_netlink.c:664:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kgid_t’
net/netlink/af_netlink.c: In function ‘netlink_ring_set_copied’:
net/netlink/af_netlink.c:693:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kuid_t’
net/netlink/af_netlink.c:694:14: error: incompatible types when assigning to type ‘__u32’ from type ‘kgid_t’

We must use the helpers to get the uid and gid, and also take care of user_ns.

Fix suggested by Eric W. Biederman .

Signed-off-by: Nicolas Dichtel 
Signed-off-by: David S. Miller

netlink: Fix build with mmap disabled.

2013-04-23T19:39:03+00:00

net/netlink/diag.c: In function 'sk_diag_put_rings_cfg':
net/netlink/diag.c:28:17: error: 'struct netlink_sock' has no member named 'pg_vec_lock'
net/netlink/diag.c:29:29: error: 'struct netlink_sock' has no member named 'rx_ring'
net/netlink/diag.c:31:30: error: 'struct netlink_sock' has no member named 'tx_ring'
net/netlink/diag.c:33:19: error: 'struct netlink_sock' has no member named 'pg_vec_lock'

Reported-by: Randy Dunlap 
Signed-off-by: David S. Miller