1. 18 Sep, 2008 2 commits
  2. 15 Sep, 2008 1 commit
  3. 12 Sep, 2008 4 commits
    • Santwona Behera's avatar
      niu: panic on reset · cff502a3
      Santwona Behera authored
      The reset_task function in the niu driver does not reset the tx and rx
      buffers properly. This leads to panic on reset. This patch is a
      modified implementation of the previously posted fix.
      Signed-off-by: default avatarSantwona Behera <santwona.behera@sun.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cff502a3
    • David S. Miller's avatar
    • Vegard Nossum's avatar
      netlink: fix overrun in attribute iteration · 1045b03e
      Vegard Nossum authored
      kmemcheck reported this:
      
        kmemcheck: Caught 16-bit read from uninitialized memory (f6c1ba30)
        0500110001508abf050010000500000002017300140000006f72672e66726565
         i i i i i i i i i i i i i u u u u u u u u u u u u u u u u u u u
                                         ^
      
        Pid: 3462, comm: wpa_supplicant Not tainted (2.6.27-rc3-00054-g6397ab9-dirty #13)
        EIP: 0060:[<c05de64a>] EFLAGS: 00010296 CPU: 0
        EIP is at nla_parse+0x5a/0xf0
        EAX: 00000008 EBX: fffffffd ECX: c06f16c0 EDX: 00000005
        ESI: 00000010 EDI: f6c1ba30 EBP: f6367c6c ESP: c0a11e88
         DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
        CR0: 8005003b CR2: f781cc84 CR3: 3632f000 CR4: 000006d0
        DR0: c0ead9bc DR1: 00000000 DR2: 00000000 DR3: 00000000
        DR6: ffff4ff0 DR7: 00000400
         [<c05d4b23>] rtnl_setlink+0x63/0x130
         [<c05d5f75>] rtnetlink_rcv_msg+0x165/0x200
         [<c05ddf66>] netlink_rcv_skb+0x76/0xa0
         [<c05d5dfe>] rtnetlink_rcv+0x1e/0x30
         [<c05dda21>] netlink_unicast+0x281/0x290
         [<c05ddbe9>] netlink_sendmsg+0x1b9/0x2b0
         [<c05beef2>] sock_sendmsg+0xd2/0x100
         [<c05bf945>] sys_sendto+0xa5/0xd0
         [<c05bf9a6>] sys_send+0x36/0x40
         [<c05c03d6>] sys_socketcall+0x1e6/0x2c0
         [<c020353b>] sysenter_do_call+0x12/0x3f
         [<ffffffff>] 0xffffffff
      
      This is the line in nla_ok():
      
        /**
         * nla_ok - check if the netlink attribute fits into the remaining bytes
         * @nla: netlink attribute
         * @remaining: number of bytes remaining in attribute stream
         */
        static inline int nla_ok(const struct nlattr *nla, int remaining)
        {
                return remaining >= sizeof(*nla) &&
                       nla->nla_len >= sizeof(*nla) &&
                       nla->nla_len <= remaining;
        }
      
      It turns out that remaining can become negative due to alignment in
      nla_next(). But GCC promotes "remaining" to unsigned in the test
      against sizeof(*nla) above. Therefore the test succeeds, and the
      nla_for_each_attr() may access memory outside the received buffer.
      
      A short example illustrating this point is here:
      
        #include <stdio.h>
      
        main(void)
        {
                printf("%d\n", -1 >= sizeof(int));
        }
      
      ...which prints "1".
      
      This patch adds a cast in front of the sizeof so that GCC will make
      a signed comparison and fix the illegal memory dereference. With the
      patch applied, there is no kmemcheck report.
      Signed-off-by: default avatarVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1045b03e
    • Marcel Holtmann's avatar
      [Bluetooth] Fix regression from using default link policy · 7c6a329e
      Marcel Holtmann authored
      To speed up the Simple Pairing connection setup, the support for the
      default link policy has been enabled. This is in contrast to settings
      the link policy on every connection setup. Using the default link policy
      is the preferred way since there is no need to dynamically change it for
      every connection.
      
      For backward compatibility reason and to support old userspace the
      HCISETLINKPOL ioctl has been switched over to using hci_request() to
      issue the HCI command for setting the default link policy instead of
      just storing it in the HCI device structure.
      
      However the hci_request() can only be issued when the device is
      brought up. If used on a device that is registered, but still down
      it will timeout and fail. This is problematic since the command is
      put on the TX queue and the Bluetooth core tries to submit it to
      hardware that is not ready yet. The timeout for these requests is
      10 seconds and this causes a significant regression when setting up
      a new device.
      
      The userspace can perfectly handle a failure of the HCISETLINKPOL
      ioctl and will re-submit it later, but the 10 seconds delay causes
      a problem. So in case hci_request() is called on a device that is
      still down, just fail it with ENETDOWN to indicate what happens.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      7c6a329e
  4. 11 Sep, 2008 1 commit
  5. 09 Sep, 2008 6 commits
    • Neil Horman's avatar
      ipv6: Fix OOPS in ip6_dst_lookup_tail(). · e550dfb0
      Neil Horman authored
      This fixes kernel bugzilla 11469: "TUN with 1024 neighbours:
      ip6_dst_lookup_tail NULL crash"
      
      dst->neighbour is not necessarily hooked up at this point
      in the processing path, so blindly dereferencing it is
      the wrong thing to do.  This NULL check exists in other
      similar paths and this case was just an oversight.
      
      Also fix the completely wrong and confusing indentation
      here while we're at it.
      
      Based upon a patch by Evgeniy Polyakov.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e550dfb0
    • Herbert Xu's avatar
      ipsec: Restore larval states and socket policies in dump · 225f4005
      Herbert Xu authored
      The commit commit 4c563f76 ("[XFRM]:
      Speed up xfrm_policy and xfrm_state walking") inadvertently removed
      larval states and socket policies from netlink dumps.  This patch
      restores them.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      225f4005
    • David S. Miller's avatar
    • Marcel Holtmann's avatar
      [Bluetooth] Reject L2CAP connections on an insecure ACL link · e7c29cb1
      Marcel Holtmann authored
      The Security Mode 4 of the Bluetooth 2.1 specification has strict
      authentication and encryption requirements. It is the initiators job
      to create a secure ACL link. However in case of malicious devices, the
      acceptor has to make sure that the ACL is encrypted before allowing
      any kind of L2CAP connection. The only exception here is the PSM 1 for
      the service discovery protocol, because that is allowed to run on an
      insecure ACL link.
      
      Previously it was enough to reject a L2CAP connection during the
      connection setup phase, but with Bluetooth 2.1 it is forbidden to
      do any L2CAP protocol exchange on an insecure link (except SDP).
      
      The new hci_conn_check_link_mode() function can be used to check the
      integrity of an ACL link. This functions also takes care of the cases
      where Security Mode 4 is disabled or one of the devices is based on
      an older specification.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      e7c29cb1
    • Marcel Holtmann's avatar
      [Bluetooth] Enforce correct authentication requirements · 09ab6f4c
      Marcel Holtmann authored
      With the introduction of Security Mode 4 and Simple Pairing from the
      Bluetooth 2.1 specification it became mandatory that the initiator
      requires authentication and encryption before any L2CAP channel can
      be established. The only exception here is PSM 1 for the service
      discovery protocol (SDP). It is meant to be used without any encryption
      since it contains only public information. This is how Bluetooth 2.0
      and before handle connections on PSM 1.
      
      For Bluetooth 2.1 devices the pairing procedure differentiates between
      no bonding, general bonding and dedicated bonding. The L2CAP layer
      wrongly uses always general bonding when creating new connections, but it
      should not do this for SDP connections. In this case the authentication
      requirement should be no bonding and the just-works model should be used,
      but in case of non-SDP connection it is required to use general bonding.
      
      If the new connection requires man-in-the-middle (MITM) protection, it
      also first wrongly creates an unauthenticated link key and then later on
      requests an upgrade to an authenticated link key to provide full MITM
      protection. With Simple Pairing the link key generation is an expensive
      operation (compared to Bluetooth 2.0 and before) and doing this twice
      during a connection setup causes a noticeable delay when establishing
      a new connection. This should be avoided to not regress from the expected
      Bluetooth 2.0 connection times. The authentication requirements are known
      up-front and so enforce them.
      
      To fulfill these requirements the hci_connect() function has been extended
      with an authentication requirement parameter that will be stored inside
      the connection information and can be retrieved by userspace at any
      time. This allows the correct IO capabilities exchange and results in
      the expected behavior.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      09ab6f4c
    • Marcel Holtmann's avatar
      [Bluetooth] Fix reference counting during ACL config stage · f1c08ca5
      Marcel Holtmann authored
      The ACL config stage keeps holding a reference count on incoming
      connections when requesting the extended features. This results in
      keeping an ACL link up without any users. The problem here is that
      the Bluetooth specification doesn't define an ownership of the ACL
      link and thus it can happen that the implementation on the initiator
      side doesn't care about disconnecting unused links. In this case the
      acceptor needs to take care of this.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      f1c08ca5
  6. 08 Sep, 2008 26 commits