1. 15 7月, 2008 4 次提交
    • M
      [Bluetooth] Make use of the default link policy settings · e4e8e37c
      Marcel Holtmann 提交于
      The Bluetooth specification supports the default link policy settings
      on a per host controller basis. For every new connection the link
      manager would then use these settings. It is better to use this instead
      of bothering the controller on every connection setup to overwrite the
      default settings.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e4e8e37c
    • M
      [Bluetooth] Track connection packet type changes · a8746417
      Marcel Holtmann 提交于
      The connection packet type can be changed after the connection has been
      established and thus needs to be properly tracked to ensure that the
      host stack has always correct and valid information about it.
      
      On incoming connections the Bluetooth core switches the supported packet
      types to the configured list for this controller. However the usefulness
      of this feature has been questioned a lot. The general consent is that
      every Bluetooth host stack should enable as many packet types as the
      hardware actually supports and leave the decision to the link manager
      software running on the Bluetooth chip.
      
      When running on Bluetooth 2.0 or later hardware, don't change the packet
      type for incoming connections anymore. This hardware likely supports
      Enhanced Data Rate and thus leave it completely up to the link manager
      to pick the best packet type.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a8746417
    • M
      [Bluetooth] Disconnect when encryption gets disabled · 9719f8af
      Marcel Holtmann 提交于
      The Bluetooth specification allows to enable or disable the encryption
      of an ACL link at any time by either the peer or the remote device. If
      a L2CAP or RFCOMM connection requested an encrypted link, they will now
      disconnect that link if the encryption gets disabled. Higher protocols
      that don't care about encryption (like SDP) are not affected.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      9719f8af
    • M
      [Bluetooth] Enforce security for outgoing RFCOMM connections · 77db1980
      Marcel Holtmann 提交于
      Recent tests with various Bluetooth headsets have shown that some of
      them don't enforce authentication and encryption when connecting. All
      of them leave it up to the host stack to enforce it. Non of them should
      allow unencrypted connections, but that is how it is. So in case the
      link mode settings require authentication and/or encryption it will now
      also be enforced on outgoing RFCOMM connections. Previously this was
      only done for incoming connections.
      
      This support has a small drawback from a protocol level point of view
      since the host stack can't really tell with 100% certainty if a remote
      side is already authenticated or not. So if both sides are configured
      to enforce authentication it will be requested twice. Most Bluetooth
      chips are caching this information and thus no extra authentication
      procedure has to be triggered over-the-air, but it can happen.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      77db1980
  2. 02 7月, 2008 1 次提交
  3. 01 7月, 2008 1 次提交
  4. 21 6月, 2008 1 次提交
    • E
      netns: Don't receive new packets in a dead network namespace. · b9f75f45
      Eric W. Biederman 提交于
      Alexey Dobriyan <adobriyan@gmail.com> writes:
      > Subject: ICMP sockets destruction vs ICMP packets oops
      
      > After icmp_sk_exit() nuked ICMP sockets, we get an interrupt.
      > icmp_reply() wants ICMP socket.
      >
      > Steps to reproduce:
      >
      > 	launch shell in new netns
      > 	move real NIC to netns
      > 	setup routing
      > 	ping -i 0
      > 	exit from shell
      >
      > BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
      > IP: [<ffffffff803fce17>] icmp_sk+0x17/0x30
      > PGD 17f3cd067 PUD 17f3ce067 PMD 0 
      > Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
      > CPU 0 
      > Modules linked in: usblp usbcore
      > Pid: 0, comm: swapper Not tainted 2.6.26-rc6-netns-ct #4
      > RIP: 0010:[<ffffffff803fce17>]  [<ffffffff803fce17>] icmp_sk+0x17/0x30
      > RSP: 0018:ffffffff8057fc30  EFLAGS: 00010286
      > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff81017c7db900
      > RDX: 0000000000000034 RSI: ffff81017c7db900 RDI: ffff81017dc41800
      > RBP: ffffffff8057fc40 R08: 0000000000000001 R09: 000000000000a815
      > R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff8057fd28
      > R13: ffffffff8057fd00 R14: ffff81017c7db938 R15: ffff81017dc41800
      > FS:  0000000000000000(0000) GS:ffffffff80525000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      > CR2: 0000000000000000 CR3: 000000017fcda000 CR4: 00000000000006e0
      > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      > Process swapper (pid: 0, threadinfo ffffffff8053a000, task ffffffff804fa4a0)
      > Stack:  0000000000000000 ffff81017c7db900 ffffffff8057fcf0 ffffffff803fcfe4
      >  ffffffff804faa38 0000000000000246 0000000000005a40 0000000000000246
      >  000000000001ffff ffff81017dd68dc0 0000000000005a40 0000000055342436
      > Call Trace:
      >  <IRQ>  [<ffffffff803fcfe4>] icmp_reply+0x44/0x1e0
      >  [<ffffffff803d3a0a>] ? ip_route_input+0x23a/0x1360
      >  [<ffffffff803fd645>] icmp_echo+0x65/0x70
      >  [<ffffffff803fd300>] icmp_rcv+0x180/0x1b0
      >  [<ffffffff803d6d84>] ip_local_deliver+0xf4/0x1f0
      >  [<ffffffff803d71bb>] ip_rcv+0x33b/0x650
      >  [<ffffffff803bb16a>] netif_receive_skb+0x27a/0x340
      >  [<ffffffff803be57d>] process_backlog+0x9d/0x100
      >  [<ffffffff803bdd4d>] net_rx_action+0x18d/0x250
      >  [<ffffffff80237be5>] __do_softirq+0x75/0x100
      >  [<ffffffff8020c97c>] call_softirq+0x1c/0x30
      >  [<ffffffff8020f085>] do_softirq+0x65/0xa0
      >  [<ffffffff80237af7>] irq_exit+0x97/0xa0
      >  [<ffffffff8020f198>] do_IRQ+0xa8/0x130
      >  [<ffffffff80212ee0>] ? mwait_idle+0x0/0x60
      >  [<ffffffff8020bc46>] ret_from_intr+0x0/0xf
      >  <EOI>  [<ffffffff80212f2c>] ? mwait_idle+0x4c/0x60
      >  [<ffffffff80212f23>] ? mwait_idle+0x43/0x60
      >  [<ffffffff8020a217>] ? cpu_idle+0x57/0xa0
      >  [<ffffffff8040f380>] ? rest_init+0x70/0x80
      > Code: 10 5b 41 5c 41 5d 41 5e c9 c3 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 53
      > 48 83 ec 08 48 8b 9f 78 01 00 00 e8 2b c7 f1 ff 89 c0 <48> 8b 04 c3 48 83 c4 08
      > 5b c9 c3 66 66 66 66 66 2e 0f 1f 84 00
      > RIP  [<ffffffff803fce17>] icmp_sk+0x17/0x30
      >  RSP <ffffffff8057fc30>
      > CR2: 0000000000000000
      > ---[ end trace ea161157b76b33e8 ]---
      > Kernel panic - not syncing: Aiee, killing interrupt handler!
      
      Receiving packets while we are cleaning up a network namespace is a
      racy proposition. It is possible when the packet arrives that we have
      removed some but not all of the state we need to fully process it.  We
      have the choice of either playing wack-a-mole with the cleanup routines
      or simply dropping packets when we don't have a network namespace to
      handle them.
      
      Since the check looks inexpensive in netif_receive_skb let's just
      drop the incoming packets.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9f75f45
  5. 20 6月, 2008 1 次提交
  6. 18 6月, 2008 1 次提交
  7. 13 6月, 2008 1 次提交
    • D
      tcp: Revert 'process defer accept as established' changes. · ec0a1966
      David S. Miller 提交于
      This reverts two changesets, ec3c0982
      ("[TCP]: TCP_DEFER_ACCEPT updates - process as established") and
      the follow-on bug fix 9ae27e0a
      ("tcp: Fix slab corruption with ipv6 and tcp6fuzz").
      
      This change causes several problems, first reported by Ingo Molnar
      as a distcc-over-loopback regression where connections were getting
      stuck.
      
      Ilpo Järvinen first spotted the locking problems.  The new function
      added by this code, tcp_defer_accept_check(), only has the
      child socket locked, yet it is modifying state of the parent
      listening socket.
      
      Fixing that is non-trivial at best, because we can't simply just grab
      the parent listening socket lock at this point, because it would
      create an ABBA deadlock.  The normal ordering is parent listening
      socket --> child socket, but this code path would require the
      reverse lock ordering.
      
      Next is a problem noticed by Vitaliy Gusev, he noted:
      
      ----------------------------------------
      >--- a/net/ipv4/tcp_timer.c
      >+++ b/net/ipv4/tcp_timer.c
      >@@ -481,6 +481,11 @@ static void tcp_keepalive_timer (unsigned long data)
      > 		goto death;
      > 	}
      >
      >+	if (tp->defer_tcp_accept.request && sk->sk_state == TCP_ESTABLISHED) {
      >+		tcp_send_active_reset(sk, GFP_ATOMIC);
      >+		goto death;
      
      Here socket sk is not attached to listening socket's request queue. tcp_done()
      will not call inet_csk_destroy_sock() (and tcp_v4_destroy_sock() which should
      release this sk) as socket is not DEAD. Therefore socket sk will be lost for
      freeing.
      ----------------------------------------
      
      Finally, Alexey Kuznetsov argues that there might not even be any
      real value or advantage to these new semantics even if we fix all
      of the bugs:
      
      ----------------------------------------
      Hiding from accept() sockets with only out-of-order data only
      is the only thing which is impossible with old approach. Is this really
      so valuable? My opinion: no, this is nothing but a new loophole
      to consume memory without control.
      ----------------------------------------
      
      So revert this thing for now.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec0a1966
  8. 11 6月, 2008 2 次提交
  9. 05 6月, 2008 7 次提交
  10. 04 6月, 2008 1 次提交
  11. 23 5月, 2008 1 次提交
  12. 20 5月, 2008 1 次提交
  13. 17 5月, 2008 1 次提交
    • I
      mac80211: Add RTNL version of ieee80211_iterate_active_interfaces · 2f561feb
      Ivo van Doorn 提交于
      Since commit e38bad47
      	mac80211: make ieee80211_iterate_active_interfaces not need rtnl
      rt2500usb and rt73usb broke down due to attempting register access
      in atomic context (which is not possible for USB hardware).
      
      This patch restores ieee80211_iterate_active_interfaces() to use RTNL lock,
      and provides the non-RTNL version under a new name:
      	ieee80211_iterate_active_interfaces_atomic()
      
      So far only rt2x00 uses ieee80211_iterate_active_interfaces(), and those
      drivers require the RTNL version of ieee80211_iterate_active_interfaces().
      Since they already call that function directly, this patch will automatically
      fix the USB rt2x00 drivers.
      
      v2: Rename ieee80211_iterate_active_interfaces_rtnl
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2f561feb
  14. 15 5月, 2008 2 次提交
    • E
      9p: fix error path during early mount · 887b3ece
      Eric Van Hensbergen 提交于
      There was some cleanup issues during early mount which would trigger
      a kernel bug for certain types of failure.  This patch reorganizes the
      cleanup to get rid of the bad behavior.
      
      This also merges the 9pnet and 9pnet_fd modules for the purpose of
      configuration and initialization.  Keeping the fd transport separate
      from the core 9pnet code seemed like a good idea at the time, but in
      practice has caused more harm and confusion than good.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      887b3ece
    • E
      9p: Documentation updates · ee443996
      Eric Van Hensbergen 提交于
      The kernel-doc comments of much of the 9p system have been in disarray since
      reorganization.  This patch fixes those problems, adds additional documentation
      and a template book which collects the 9p information.
      Signed-off-by: NEric Van Hensbergen <ericvh@gmail.com>
      ee443996
  15. 14 5月, 2008 1 次提交
  16. 12 5月, 2008 1 次提交
    • D
      syncppp: Fix crashes. · 4951704b
      David S. Miller 提交于
      The syncppp layer wants a mid-level netdev private pointer.
      
      It was using netdev->priv but that only worked by accident,
      and thus this scheme was broken when the device private
      allocation strategy changed.
      
      Add a proper mid-layer private pointer for uses like this,
      update syncppp and all users, and remove the HDLC_PPP broken
      tag from drivers/net/wan/Kconfig
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4951704b
  17. 05 5月, 2008 1 次提交
  18. 04 5月, 2008 1 次提交
    • M
      xfrm: convert empty xfrm_audit_* macros to functions · 41fef0ee
      Marcin Slusarz 提交于
      it removes these warnings when CONFIG_AUDITSYSCALL is unset:
      
      net/xfrm/xfrm_user.c: In function 'xfrm_add_sa':
      net/xfrm/xfrm_user.c:412: warning: unused variable 'sid'
      net/xfrm/xfrm_user.c:411: warning: unused variable 'sessionid'
      net/xfrm/xfrm_user.c:410: warning: unused variable 'loginuid'
      net/xfrm/xfrm_user.c: In function 'xfrm_del_sa':
      net/xfrm/xfrm_user.c:485: warning: unused variable 'sid'
      net/xfrm/xfrm_user.c:484: warning: unused variable 'sessionid'
      net/xfrm/xfrm_user.c:483: warning: unused variable 'loginuid'
      net/xfrm/xfrm_user.c: In function 'xfrm_add_policy':
      net/xfrm/xfrm_user.c:1132: warning: unused variable 'sid'
      net/xfrm/xfrm_user.c:1131: warning: unused variable 'sessionid'
      net/xfrm/xfrm_user.c:1130: warning: unused variable 'loginuid'
      net/xfrm/xfrm_user.c: In function 'xfrm_get_policy':
      net/xfrm/xfrm_user.c:1382: warning: unused variable 'sid'
      net/xfrm/xfrm_user.c:1381: warning: unused variable 'sessionid'
      net/xfrm/xfrm_user.c:1380: warning: unused variable 'loginuid'
      net/xfrm/xfrm_user.c: In function 'xfrm_add_pol_expire':
      net/xfrm/xfrm_user.c:1620: warning: unused variable 'sid'
      net/xfrm/xfrm_user.c:1619: warning: unused variable 'sessionid'
      net/xfrm/xfrm_user.c:1618: warning: unused variable 'loginuid'
      net/xfrm/xfrm_user.c: In function 'xfrm_add_sa_expire':
      net/xfrm/xfrm_user.c:1658: warning: unused variable 'sid'
      net/xfrm/xfrm_user.c:1657: warning: unused variable 'sessionid'
      net/xfrm/xfrm_user.c:1656: warning: unused variable 'loginuid'
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      41fef0ee
  19. 29 4月, 2008 4 次提交
  20. 28 4月, 2008 2 次提交
  21. 24 4月, 2008 1 次提交
  22. 22 4月, 2008 1 次提交
    • H
      [IPSEC]: Fix catch-22 with algorithm IDs above 31 · c5d18e98
      Herbert Xu 提交于
      As it stands it's impossible to use any authentication algorithms
      with an ID above 31 portably.  It just happens to work on x86 but
      fails miserably on ppc64.
      
      The reason is that we're using a bit mask to check the algorithm
      ID but the mask is only 32 bits wide.
      
      After looking at how this is used in the field, I have concluded
      that in the long term we should phase out state matching by IDs
      because this is made superfluous by the reqid feature.  For current
      applications, the best solution IMHO is to allow all algorithms when
      the bit masks are all ~0.
      
      The following patch does exactly that.
      
      This bug was identified by IBM when testing on the ppc64 platform
      using the NULL authentication algorithm which has an ID of 251.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5d18e98
  23. 18 4月, 2008 2 次提交
  24. 17 4月, 2008 1 次提交