Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 5月, 2010 1 次提交
    • J
      mac80211: don't process work item with wrong frame · b8d92c9c
      由 Johannes Berg 提交于 
      When we process a frame, we currently just match it
to the work struct by the MAC addresses, and not by
the work type. This means that we can end up doing
the work for an association request item when (for
whatever reason) we receive another frame type, for
example a probe response. Processing the wrong type
of frame will lead to completely invalid data being
processed, and will lead to various problems like
thinking the association was successful even if the
AP never sent an assocation response.

Fix this by making each processing function check
that it is invoked for the right work struct type
only and continue processing otherwise (and drop
frames that we didn't expect).

This bug was uncovered during the debugging for
https://bugzilla.kernel.org/show_bug.cgi?id=15862
but doesn't seem to be the cause for any of the
various problems reported there.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b8d92c9c
  3. 08 5月, 2010 1 次提交
    • R
      mac80211: remove association work when processing deauth request · 79733a86
      由 Reinette Chatre 提交于 
      In https://bugzilla.kernel.org/show_bug.cgi?id=15794 a user encountered the
following:

[18967.469098] wlan0: authenticated
[18967.472527] wlan0: associate with 00:1c:10:b8:e3:ea (try 1)
[18967.472585] wlan0: deauthenticating from 00:1c:10:b8:e3:ea by local choice (reason=3)
[18967.672057] wlan0: associate with 00:1c:10:b8:e3:ea (try 2)
[18967.872357] wlan0: associate with 00:1c:10:b8:e3:ea (try 3)
[18968.072960] wlan0: association with 00:1c:10:b8:e3:ea timed out
[18968.076890] ------------[ cut here ]------------
[18968.076898] WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0xa8/0x140()
[18968.076900] Hardware name: GX628
[18968.076924] Pid: 1408, comm: phy0 Not tainted 2.6.34-rc4-00082-g250541fc-dirty #3
[18968.076926] Call Trace:
[18968.076931]  [<ffffffff8103459e>] ?  warn_slowpath_common+0x6e/0xb0
[18968.076934]  [<ffffffff8157c2d8>] ?  cfg80211_send_assoc_timeout+0xa8/0x140
[18968.076937]  [<ffffffff8103ff8b>] ? mod_timer+0x10b/0x180
[18968.076940]  [<ffffffff8158f0fc>] ?  ieee80211_assoc_done+0xbc/0xc0
[18968.076943]  [<ffffffff81590d53>] ?  ieee80211_work_work+0x553/0x11c0
[18968.076945]  [<ffffffff8102d931>] ? finish_task_switch+0x41/0xb0
[18968.076948]  [<ffffffff81590800>] ?  ieee80211_work_work+0x0/0x11c0
[18968.076951]  [<ffffffff810476fb>] ? worker_thread+0x13b/0x210
[18968.076954]  [<ffffffff8104b6b0>] ?  autoremove_wake_function+0x0/0x30
[18968.076956]  [<ffffffff810475c0>] ? worker_thread+0x0/0x210
[18968.076959]  [<ffffffff8104b21e>] ? kthread+0x8e/0xa0
[18968.076962]  [<ffffffff810031f4>] ?  kernel_thread_helper+0x4/0x10
[18968.076964]  [<ffffffff8104b190>] ? kthread+0x0/0xa0
[18968.076966]  [<ffffffff810031f0>] ?  kernel_thread_helper+0x0/0x10
[18968.076968] ---[ end trace 8aa6265f4b1adfe0 ]---

As explained by Johannes Berg <johannes@sipsolutions.net>:

We authenticate successfully, and then userspace requests association.
Then we start that process, but the AP doesn't respond. While we're
still waiting for an AP response, userspace asks for a deauth. We do
the deauth, but don't abort the association work. Then once the
association work times out we tell cfg80211, but it no longer wants
to know since for all it is concerned we accepted the deauth that
also kills the association attempt.

Fix this by, upon receipt of deauth request, removing the association work
and continuing to send the deauth.

Unfortunately the user reporting the issue is not able to reproduce this
problem anymore and cannot verify this fix. This seems like a well understood
issue though and I thus present the patch.
Bug-identified-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      79733a86
  5. 20 4月, 2010 2 次提交
  7. 07 4月, 2010 2 次提交
  9. 31 3月, 2010 4 次提交
  11. 11 3月, 2010 3 次提交
  13. 09 3月, 2010 8 次提交
  15. 08 3月, 2010 5 次提交
  17. 06 3月, 2010 10 次提交
  19. 04 3月, 2010 4 次提交
    • N
      tipc: Fix oops on send prior to entering networked mode (v3) · d0021b25
      由 Neil Horman 提交于 
      Fix TIPC to disallow sending to remote addresses prior to entering NET_MODE

user programs can oops the kernel by sending datagrams via AF_TIPC prior to
entering networked mode.  The following backtrace has been observed:

ID: 13459  TASK: ffff810014640040  CPU: 0   COMMAND: "tipc-client"
[exception RIP: tipc_node_select_next_hop+90]
RIP: ffffffff8869d3c3  RSP: ffff81002d9a5ab8  RFLAGS: 00010202
RAX: 0000000000000001  RBX: 0000000000000001  RCX: 0000000000000001
RDX: 0000000000000000  RSI: 0000000000000001  RDI: 0000000001001001
RBP: 0000000001001001   R8: 0074736575716552   R9: 0000000000000000
R10: ffff81003fbd0680  R11: 00000000000000c8  R12: 0000000000000008
R13: 0000000000000001  R14: 0000000000000001  R15: ffff810015c6ca00
ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
RIP: 0000003cbd8d49a3  RSP: 00007fffc84e0be8  RFLAGS: 00010206
RAX: 000000000000002c  RBX: ffffffff8005d116  RCX: 0000000000000000
RDX: 0000000000000008  RSI: 00007fffc84e0c00  RDI: 0000000000000003
RBP: 0000000000000000   R8: 00007fffc84e0c10   R9: 0000000000000010
R10: 0000000000000000  R11: 0000000000000246  R12: 0000000000000000
R13: 00007fffc84e0d10  R14: 0000000000000000  R15: 00007fffc84e0c30
ORIG_RAX: 000000000000002c  CS: 0033  SS: 002b

What happens is that, when the tipc module in inserted it enters a standalone
node mode in which communication to its own address is allowed <0.0.0> but not
to other addresses, since the appropriate data structures have not been
allocated yet (specifically the tipc_net pointer).  There is nothing stopping a
client from trying to send such a message however, and if that happens, we
attempt to dereference tipc_net.zones while the pointer is still NULL, and
explode.  The fix is pretty straightforward.  Since these oopses all arise from
the dereference of global pointers prior to their assignment to allocated
values, and since these allocations are small (about 2k total), lets convert
these pointers to static arrays of the appropriate size.  All the accesses to
these bits consider 0/NULL to be a non match when searching, so all the lookups
still work properly, and there is no longer a chance of a bad dererence
anywhere.  As a bonus, this lets us eliminate the setup/teardown routines for
those pointers, and elimnates the need to preform any locking around them to
prevent access while their being allocated/freed.

I've updated the tipc_net structure to behave this way to fix the exact reported
problem, and also fixed up the tipc_bearers and media_list arrays to fix an
obvious simmilar problem that arises from issuing tipc-config commands to
manipulate bearers/links prior to entering networked mode

I've tested this for a few hours by running the sanity tests and stress test
with the tipcutils suite, and nothing has fallen over.  There have been a few
lockdep warnings, but those were there before, and can be addressed later, as
they didn't actually result in any deadlock.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
CC: Allan Stephens <allan.stephens@windriver.com>
CC: David S. Miller <davem@davemloft.net>
CC: tipc-discussion@lists.sourceforge.net

 bearer.c |   37 ++++++-------------------------------
 bearer.h |    2 +-
 net.c    |   25 ++++---------------------
 3 files changed, 11 insertions(+), 53 deletions(-)
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0021b25
    • T
      gre: fix hard header destination address checking · 6d55cb91
      由 Timo Teräs 提交于 
      ipgre_header() can be called with zero daddr when the gre device is
configured as multipoint tunnel and still has the NOARP flag set (which is
typically cleared by the userspace arp daemon).  If the NOARP packets are
not dropped, ipgre_tunnel_xmit() will take rt->rt_gateway (= NBMA IP) and
use that for route look up (and may lead to bogus xfrm acquires).

The multicast address check is removed as sending to multicast group should
be ok.  In fact, if gre device has a multicast address as destination
ipgre_header is always called with multicast address.
Signed-off-by: NTimo Teras <timo.teras@iki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d55cb91
    • S
      IPv6: fix race between cleanup and add/delete address · 8f37ada5
      由 stephen hemminger 提交于 
      This solves a potential race problem during the cleanup process.
The issue is that addrconf_ifdown() needs to traverse address list,
but then drop lock to call the notifier. The version in -next
could get confused if add/delete happened during this window.
Original code (2.6.32 and earlier) was okay because all addresses
were always deleted.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f37ada5
    • S
      IPv6: addrconf notify when address is unavailable · 84e8b803
      由 stephen hemminger 提交于 
      My recent change in net-next to retain permanent addresses caused regression.
Device refcount would not go to zero when device was unregistered because
left over anycast reference would hold ipv6 dev reference which would hold
device references...

The correct procedure is to call notify chain when address is no longer
available for use.  When interface comes back DAD timer will notify
back that address is available.

Also, link local addresses should be purged when interface is brought
down. The address might be changed.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84e8b803