kernel/linux.git/net, branch v3.1.3

batman-adv: unify hash_entry field position in tt_local/global_entry

2011-11-26T17:08:40+00:00

commit 93840ac40bb0d0f177ef8af74e64671be67e8c37 upstream. Function tt_response_fill_table() actually uses a tt_local_entry pointer to iterate either over the local or the global table entries (it depends on the what hash table is passed as argument). To iterate over such entries the hlist_for_each_entry_rcu() macro has to access their "hash_entry" field which MUST be at the same position in both the tt_global/local_entry structures. Reported-by: Simon Wunderlich Signed-off-by: Antonio Quartulli Signed-off-by: Marek Lindner Signed-off-by: Greg Kroah-Hartman

batman-adv: add sanity check when removing global tts

2011-11-26T17:08:39+00:00

commit 6e8014947d6469df1566e9e253805557c5c0e4e0 upstream. After removing the batman-adv module, the hash may be already gone when tt_global_del_orig() tries to clean the hash. This patch adds a sanity check to avoid this. Signed-off-by: Simon Wunderlich Tested-by: Alexey Fisher Signed-off-by: Marek Lindner Signed-off-by: Greg Kroah-Hartman

batman-adv: remove references for global tt entries

2011-11-26T17:08:39+00:00

commit 531027fcddbcf81c9937dd04f08a7e8f11fd47d2 upstream. struct tt_global_entry holds a reference to an orig_node which must be decremented before deallocating the structure. Signed-off-by: Simon Wunderlich Tested-by: Alexey Fisher Signed-off-by: Marek Lindner Signed-off-by: Greg Kroah-Hartman

batman-adv: correctly set the data field in the TT_REPONSE packet

2011-11-26T17:08:39+00:00

commit 9d8523931f7f5eb8900077f0da0fbe6b8ad0010b upstream. In the TT_RESPONSE packet, the number of carried entries is not correctly set. This leads to a wrong interpretation of the packet payload on the receiver side causing random entries to be added to the global translation table. Therefore the latter gets always corrupted, triggering a table recovery all the time. Signed-off-by: Antonio Quartulli Signed-off-by: Marek Lindner Signed-off-by: Greg Kroah-Hartman

batman-adv: fix tt_local_reset_flags() function

2011-11-26T17:08:39+00:00

commit 31901264511cf20c5ed33b8649a3ca9ce28df60b upstream. Currently the counter of tt_local_entry structures (tt_local_num) is incremented each time the tt_local_reset_flags() is invoked causing the node to send wrong TT_REPONSE packets containing a copy of non-initialised memory thus corrupting other nodes global translation table and making higher level communication impossible. Reported-by: Junkeun Song Signed-off-by: Antonio Quartulli Acked-by: Junkeun Song Signed-off-by: Marek Lindner Signed-off-by: Greg Kroah-Hartman

ip6_tunnel: copy parms.name after register_netdevice

2011-11-26T17:08:34+00:00

commit 731abb9cb27aef6013ce60808a04e04a545f3f4e upstream. Commit 1c5cae815d removed an explicit call to dev_alloc_name in ip6_tnl_create because register_netdevice will now create a valid name. This works for the net_device itself. However the tunnel keeps a copy of the name in the parms structure for the ip6_tnl associated with the tunnel. parms.name is set by copying the net_device name in ip6_tnl_dev_init_gen. That function is called from ip6_tnl_dev_init in ip6_tnl_create, but it is done before register_netdevice is called so the name is set to a bogus value in the parms.name structure. This shows up if you do a simple tunnel add, followed by a tunnel show: [root@localhost ~]# ip -6 tunnel add remote fec0::100 local fec0::200 [root@localhost ~]# ip -6 tunnel show ip6tnl0: ipv6/ipv6 remote :: local :: encaplimit 0 hoplimit 0 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) ip6tnl%d: ipv6/ipv6 remote fec0::100 local fec0::200 encaplimit 4 hoplimit 64 tclass 0x00 flowlabel 0x00000 (flowinfo 0x00000000) [root@localhost ~]# Fix this by moving the strcpy out of ip6_tnl_dev_init_gen, and calling it after register_netdevice has successfully returned. Signed-off-by: Josh Boyer Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

cfg80211: fix bug on regulatory core exit on access to last_request

2011-11-26T17:08:34+00:00

commit 58ebacc66bd11be2327edcefc79de94bd6f5bb4a upstream. Commit 4d9d88d1 by Scott James Remnant added the .uevent() callback for the regulatory device used during the platform device registration. The change was done to account for queuing up udev change requests through udevadm triggers. The change also meant that upon regulatory core exit we will now send a uevent() but the uevent() callback, reg_device_uevent(), also accessed last_request. Right before commiting device suicide we free'd last_request but never set it to NULL so platform_device_unregister() would lead to bogus kernel paging request. Fix this and also simply supress uevents right before we commit suicide as they are pointless. This fix is required for kernels >= v2.6.39 $ git describe --contains 4d9d88d1 v2.6.39-rc1~468^2~25^2^2~21 The impact of not having this present is that a bogus paging access may occur (only read) upon cfg80211 unload time. You may also get this BUG complaint below. Although Johannes could not reproduce the issue this fix is theoretically correct. mac80211_hwsim: unregister radios mac80211_hwsim: closing netlink BUG: unable to handle kernel paging request at ffff88001a06b5ab IP: [] reg_device_uevent+0x1a/0x50 [cfg80211] PGD 1836063 PUD 183a063 PMD 1ffcb067 PTE 1a06b160 Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU 0 Modules linked in: cfg80211(-) [last unloaded: mac80211] Pid: 2279, comm: rmmod Tainted: G W 3.1.0-wl+ #663 Bochs Bochs RIP: 0010:[] [] reg_device_uevent+0x1a/0x50 [cfg80211] RSP: 0000:ffff88001c5f9d58 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88001d2eda88 RCX: ffff88001c7468fc RDX: ffff88001a06b5a0 RSI: ffff88001c7467b0 RDI: ffff88001c7467b0 RBP: ffff88001c5f9d58 R08: 000000000000ffff R09: 000000000000ffff R10: 0000000000000000 R11: 0000000000000001 R12: ffff88001c7467b0 R13: ffff88001d2eda78 R14: ffffffff8164a840 R15: 0000000000000001 FS: 00007f8a91d8a6e0(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffff88001a06b5ab CR3: 000000001c62e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process rmmod (pid: 2279, threadinfo ffff88001c5f8000, task ffff88000023c780) Stack: ffff88001c5f9d98 ffffffff812ff7e5 ffffffff8176ab3d ffff88001c7468c2 000000000000ffff ffff88001d2eda88 ffff88001c7467b0 ffff880000114820 ffff88001c5f9e38 ffffffff81241dc7 ffff88001c5f9db8 ffffffff81040189 Call Trace: [] dev_uevent+0xc5/0x170 [] kobject_uevent_env+0x1f7/0x490 [] ? sub_preempt_count+0x29/0x60 [] ? _raw_spin_unlock_irqrestore+0x4a/0x90 [] ? devres_release_all+0x27/0x60 [] kobject_uevent+0xb/0x10 [] device_del+0x157/0x1b0 [] platform_device_del+0x1d/0x90 [] platform_device_unregister+0x16/0x30 [] regulatory_exit+0x5d/0x180 [cfg80211] [] cfg80211_exit+0x2b/0x45 [cfg80211] [] sys_delete_module+0x16c/0x220 [] ? trace_hardirqs_on_caller+0x7e/0x120 [] system_call_fastpath+0x16/0x1b Code: RIP [] reg_device_uevent+0x1a/0x50 [cfg80211] RSP CR2: ffff88001a06b5ab ---[ end trace 147c5099a411e8c0 ]--- Reported-by: Johannes Berg Cc: Scott James Remnant Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

nl80211: fix HT capability attribute validation

2011-11-26T17:08:34+00:00

commit 6c7394197af90f6a332180e33f5d025d3037d883 upstream. Since the NL80211_ATTR_HT_CAPABILITY attribute is used as a struct, it needs a minimum, not maximum length. Enforce that properly. Not doing so could potentially lead to reading after the buffer. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mac80211: fix bug in ieee80211_build_probe_req

2011-11-26T17:08:34+00:00

commit 5b2bbf75a24d6b06afff6de0eb4819413fd81971 upstream. ieee80211_probereq_get() can return NULL in which case we should clean up & return NULL in ieee80211_build_probe_req() as well. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

mac80211: fix NULL dereference in radiotap code

2011-11-26T17:08:34+00:00

commit f8d1ccf15568268c76f913b45ecdd33134387f1a upstream. When receiving failed PLCP frames is enabled, there won't be a rate pointer when we add the radiotap header and thus the kernel will crash. Fix this by not assuming the rate pointer is always valid. It's still always valid for frames that have good PLCP though, and that is checked & enforced. This was broken by my commit fc88518916793af8ad6a02e05ff254d95c36d875 Author: Johannes Berg Date: Fri Jul 30 13:23:12 2010 +0200 mac80211: don't check rates on PLCP error frames where I removed the check in this case but didn't take into account that the rate info would be used. Reported-by: Xiaokang Qin Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman