1. 20 3月, 2015 4 次提交
  2. 19 3月, 2015 16 次提交
  3. 18 3月, 2015 20 次提交
    • M
      Bluetooth: Fix potential NULL dereference in SMP channel setup · 63511f6d
      Marcel Holtmann 提交于
      When the allocation of the L2CAP channel for the BR/EDR security manager
      fails, then the smp variable might be NULL. In that case do not try to
      free the non-existing crypto contexts
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      63511f6d
    • Y
      tipc: withdraw tipc topology server name when namespace is deleted · 2b9bb7f3
      Ying Xue 提交于
      The TIPC topology server is a per namespace service associated with the
      tipc name {1, 1}. When a namespace is deleted, that name must be withdrawn
      before we call sk_release_kernel because the kernel socket release is
      done in init_net and trying to withdraw a TIPC name published in another
      namespace will fail with an error as:
      
      [  170.093264] Unable to remove local publication
      [  170.093264] (type=1, lower=1, ref=2184244004, key=2184244005)
      
      We fix this by breaking the association between the topology server name
      and socket before calling sk_release_kernel.
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2b9bb7f3
    • Y
      tipc: fix a potential deadlock when nametable is purged · 8460504b
      Ying Xue 提交于
      [   28.531768] =============================================
      [   28.532322] [ INFO: possible recursive locking detected ]
      [   28.532322] 3.19.0+ #194 Not tainted
      [   28.532322] ---------------------------------------------
      [   28.532322] insmod/583 is trying to acquire lock:
      [   28.532322]  (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000d219>] tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
      [   28.532322]
      [   28.532322] but task is already holding lock:
      [   28.532322]  (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000e0dc>] tipc_nametbl_stop+0xfc/0x1f0 [tipc]
      [   28.532322]
      [   28.532322] other info that might help us debug this:
      [   28.532322]  Possible unsafe locking scenario:
      [   28.532322]
      [   28.532322]        CPU0
      [   28.532322]        ----
      [   28.532322]   lock(&(&nseq->lock)->rlock);
      [   28.532322]   lock(&(&nseq->lock)->rlock);
      [   28.532322]
      [   28.532322]  *** DEADLOCK ***
      [   28.532322]
      [   28.532322]  May be due to missing lock nesting notation
      [   28.532322]
      [   28.532322] 3 locks held by insmod/583:
      [   28.532322]  #0:  (net_mutex){+.+.+.}, at: [<ffffffff8163e30f>] register_pernet_subsys+0x1f/0x50
      [   28.532322]  #1:  (&(&tn->nametbl_lock)->rlock){+.....}, at: [<ffffffffa000e091>] tipc_nametbl_stop+0xb1/0x1f0 [tipc]
      [   28.532322]  #2:  (&(&nseq->lock)->rlock){+.....}, at: [<ffffffffa000e0dc>] tipc_nametbl_stop+0xfc/0x1f0 [tipc]
      [   28.532322]
      [   28.532322] stack backtrace:
      [   28.532322] CPU: 1 PID: 583 Comm: insmod Not tainted 3.19.0+ #194
      [   28.532322] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [   28.532322]  ffffffff82394460 ffff8800144cb928 ffffffff81792f3e 0000000000000007
      [   28.532322]  ffffffff82394460 ffff8800144cba28 ffffffff810a8080 ffff8800144cb998
      [   28.532322]  ffffffff810a4df3 ffff880013e9cb10 ffffffff82b0d330 ffff880013e9cb38
      [   28.532322] Call Trace:
      [   28.532322]  [<ffffffff81792f3e>] dump_stack+0x4c/0x65
      [   28.532322]  [<ffffffff810a8080>] __lock_acquire+0x740/0x1ca0
      [   28.532322]  [<ffffffff810a4df3>] ? __bfs+0x23/0x270
      [   28.532322]  [<ffffffff810a7506>] ? check_irq_usage+0x96/0xe0
      [   28.532322]  [<ffffffff810a8a73>] ? __lock_acquire+0x1133/0x1ca0
      [   28.532322]  [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
      [   28.532322]  [<ffffffff810a9c0c>] lock_acquire+0x9c/0x140
      [   28.532322]  [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
      [   28.532322]  [<ffffffff8179c41f>] _raw_spin_lock_bh+0x3f/0x50
      [   28.532322]  [<ffffffffa000d219>] ? tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
      [   28.532322]  [<ffffffffa000d219>] tipc_nametbl_remove_publ+0x49/0x2e0 [tipc]
      [   28.532322]  [<ffffffffa000e11e>] tipc_nametbl_stop+0x13e/0x1f0 [tipc]
      [   28.532322]  [<ffffffffa000dfe5>] ? tipc_nametbl_stop+0x5/0x1f0 [tipc]
      [   28.532322]  [<ffffffffa0004bab>] tipc_init_net+0x13b/0x150 [tipc]
      [   28.532322]  [<ffffffffa0004a75>] ? tipc_init_net+0x5/0x150 [tipc]
      [   28.532322]  [<ffffffff8163dece>] ops_init+0x4e/0x150
      [   28.532322]  [<ffffffff810aa66d>] ? trace_hardirqs_on+0xd/0x10
      [   28.532322]  [<ffffffff8163e1d3>] register_pernet_operations+0xf3/0x190
      [   28.532322]  [<ffffffff8163e31e>] register_pernet_subsys+0x2e/0x50
      [   28.532322]  [<ffffffffa002406a>] tipc_init+0x6a/0x1000 [tipc]
      [   28.532322]  [<ffffffffa0024000>] ? 0xffffffffa0024000
      [   28.532322]  [<ffffffff810002d9>] do_one_initcall+0x89/0x1c0
      [   28.532322]  [<ffffffff811b7cb0>] ? kmem_cache_alloc_trace+0x50/0x1b0
      [   28.532322]  [<ffffffff810e725b>] ? do_init_module+0x2b/0x200
      [   28.532322]  [<ffffffff810e7294>] do_init_module+0x64/0x200
      [   28.532322]  [<ffffffff810e9353>] load_module+0x12f3/0x18e0
      [   28.532322]  [<ffffffff810e5890>] ? show_initstate+0x50/0x50
      [   28.532322]  [<ffffffff810e9a19>] SyS_init_module+0xd9/0x110
      [   28.532322]  [<ffffffff8179f3b3>] sysenter_dispatch+0x7/0x1f
      
      Before tipc_purge_publications() calls tipc_nametbl_remove_publ() to
      remove a publication with a name sequence, the name sequence's lock
      is held. However, when tipc_nametbl_remove_publ() calling
      tipc_nameseq_remove_publ() to remove the publication, it first tries
      to query name sequence instance with the publication, and then holds
      the lock of the found name sequence. But as the lock may be already
      taken in tipc_purge_publications(), deadlock happens like above
      scenario demonstrated. As tipc_nameseq_remove_publ() doesn't grab name
      sequence's lock, the deadlock can be avoided if it's directly invoked
      by tipc_purge_publications().
      
      Fixes: 97ede29e ("tipc: convert name table read-write lock to RCU")
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8460504b
    • Y
      tipc: fix netns refcnt leak · 76100a8a
      Ying Xue 提交于
      When the TIPC module is loaded, we launch a topology server in kernel
      space, which in its turn is creating TIPC sockets for communication
      with topology server users. Because both the socket's creator and
      provider reside in the same module, it is necessary that the TIPC
      module's reference count remains zero after the server is started and
      the socket created; otherwise it becomes impossible to perform "rmmod"
      even on an idle module.
      
      Currently, we achieve this by defining a separate "tipc_proto_kern"
      protocol struct, that is used only for kernel space socket allocations.
      This structure has the "owner" field set to NULL, which restricts the
      module reference count from being be bumped when sk_alloc() for local
      sockets is called. Furthermore, we have defined three kernel-specific
      functions, tipc_sock_create_local(), tipc_sock_release_local() and
      tipc_sock_accept_local(), to avoid the module counter being modified
      when module local sockets are created or deleted. This has worked well
      until we introduced name space support.
      
      However, after name space support was introduced, we have observed that
      a reference count leak occurs, because the netns counter is not
      decremented in tipc_sock_delete_local().
      
      This commit remedies this problem. But instead of just modifying
      tipc_sock_delete_local(), we eliminate the whole parallel socket
      handling infrastructure, and start using the regular sk_create_kern(),
      kernel_accept() and sk_release_kernel() calls. Since those functions
      manipulate the module counter, we must now compensate for that by
      explicitly decrementing the counter after module local sockets are
      created, and increment it just before calling sk_release_kernel().
      
      Fixes: a62fbcce ("tipc: make subscriber server support net namespace")
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Reviewed-by: NJon Maloy <jon.maloy@ericson.com>
      Reviewed-by: NErik Hugne <erik.hugne@ericsson.com>
      Reported-by: NCong Wang <cwang@twopensource.com>
      Tested-by: NErik Hugne <erik.hugne@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76100a8a
    • E
      inet: fix request sock refcounting · 0470c8ca
      Eric Dumazet 提交于
      While testing last patch series, I found req sock refcounting was wrong.
      
      We must set skc_refcnt to 1 for all request socks added in hashes,
      but also on request sockets created by FastOpen or syncookies.
      
      It is tricky because we need to defer this initialization so that
      future RCU lookups do not try to take a refcount on a not yet
      fully initialized request socket.
      
      Also get rid of ireq_refcnt alias.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Fixes: 13854e5a ("inet: add proper refcounting to request sock")
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0470c8ca
    • E
      inet: avoid fastopen lock for regular accept() · e3d95ad7
      Eric Dumazet 提交于
      It is not because a TCP listener is FastOpen ready that
      all incoming sockets actually used FastOpen.
      
      Avoid taking queue->fastopenq->lock if not needed.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e3d95ad7
    • E
      tcp: rename struct tcp_request_sock listener · 9439ce00
      Eric Dumazet 提交于
      The listener field in struct tcp_request_sock is a pointer
      back to the listener. We now have req->rsk_listener, so TCP
      only needs one boolean and not a full pointer.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9439ce00
    • E
      inet: add rsk_listener field to struct request_sock · 4e9a578e
      Eric Dumazet 提交于
      Once we'll be able to lookup request sockets in ehash table,
      we'll need to get access to listener which created this request.
      
      This avoid doing a lookup to find the listener, which benefits
      for a more solid SO_REUSEPORT, and is needed once we no
      longer queue request sock into a listener private queue.
      
      Note that 'struct tcp_request_sock'->listener could be reduced
      to a single bit, as TFO listener should match req->rsk_listener.
      TFO will no longer need to hold a reference on the listener.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e9a578e
    • E
      inet: uninline inet_reqsk_alloc() · e49bb337
      Eric Dumazet 提交于
      inet_reqsk_alloc() is becoming fat and should not be inlined.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e49bb337
    • E
      inet: add sk_listener argument to inet_reqsk_alloc() · 407640de
      Eric Dumazet 提交于
      listener socket can be used to set net pointer, and will
      be later used to hold a reference on listener.
      
      Add a const qualifier to first argument (struct request_sock_ops *),
      and factorize all write_pnet(&ireq->ireq_net, sock_net(sk));
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      407640de
    • E
      tcp: uninline tcp_oow_rate_limited() · 7970ddc8
      Eric Dumazet 提交于
      tcp_oow_rate_limited() is hardly used in fast path, there is
      no point inlining it.
      Signed-of-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7970ddc8
    • E
      tcp: move tcp_openreq_init() to tcp_input.c · 1bfc4438
      Eric Dumazet 提交于
      This big helper is called once from tcp_conn_request(), there is no
      point having it in an include. Compiler will inline it anyway.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1bfc4438
    • E
      netfilter: xt_socket: prepare for TCP_NEW_SYN_RECV support · a9407000
      Eric Dumazet 提交于
      TCP request socks soon will be visible in ehash table.
      
      xt_socket will be able to match them, but first we need
      to make sure to not consider them as full sockets.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a9407000
    • E
      netfilter: tproxy: prepare TCP_NEW_SYN_RECV support · 8b580147
      Eric Dumazet 提交于
      TCP request socks soon will be visible in ehash table.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b580147
    • E
      netfilter: use sk_fullsock() helper · a8399231
      Eric Dumazet 提交于
      Upcoming request sockets have TCP_NEW_SYN_RECV state and should
      be special cased a bit like TCP_TIME_WAIT sockets.
      
      Signed-off-by; Eric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8399231
    • A
      bpf: allow BPF programs access 'protocol' and 'vlan_tci' fields · c2497395
      Alexei Starovoitov 提交于
      as a follow on to patch 70006af9 ("bpf: allow eBPF access skb fields")
      this patch allows 'protocol' and 'vlan_tci' fields to be accessible
      from extended BPF programs.
      
      The usage of 'protocol', 'vlan_present' and 'vlan_tci' fields is the same as
      corresponding SKF_AD_PROTOCOL, SKF_AD_VLAN_TAG_PRESENT and SKF_AD_VLAN_TAG
      accesses in classic BPF.
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c2497395
    • J
      Bluetooth: Add workaround for broken OS X legacy SMP pairing · 19c5ce9c
      Johan Hedberg 提交于
      OS X version 10.10.2 (and possibly older versions) doesn't support LE
      Secure Connections but incorrectly copies all authentication request
      bits from a Security Request to its Pairing Request. The result is that
      an SC capable initiator (such as BlueZ) will think OS X intends to do SC
      when in fact it's incapable of it:
      
      < ACL Data TX: Handle 3585 flags 0x00 dlen 6
            SMP: Security Request (0x0b) len 1
              Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
      > ACL Data RX: Handle 3585 flags 0x02 dlen 11
            SMP: Pairing Request (0x01) len 6
              IO capability: KeyboardDisplay (0x04)
              OOB data: Authentication data not present (0x00)
              Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
              Max encryption key size: 16
              Initiator key distribution: EncKey (0x01)
              Responder key distribution: EncKey IdKey Sign (0x07)
      < ACL Data TX: Handle 3585 flags 0x00 dlen 11
            SMP: Pairing Response (0x02) len 6
              IO capability: NoInputNoOutput (0x03)
              OOB data: Authentication data not present (0x00)
              Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
              Max encryption key size: 16
              Initiator key distribution: EncKey (0x01)
              Responder key distribution: EncKey Sign (0x05)
      
      The pairing eventually fails when we get an unexpected Pairing Confirm
      PDU instead of a Public Key PDU:
      
      > ACL Data RX: Handle 3585 flags 0x02 dlen 21
            SMP: Pairing Confirm (0x03) len 16
              Confim value: bcc3bed31b8f313a78ec3cce32685faf
      
      It is only at this point that we can speculate that the remote doesn't
      really support SC. This patch creates a workaround for the just-works
      model, however the MITM case is unsolvable because the OS X user has
      already been requested to enter a PIN which we're now expected to
      randomly generate and show the user (i.e. a chicken-and-egg problem).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      19c5ce9c
    • J
      Bluetooth: Move generic mgmt command dispatcher to hci_sock.c · fa4335d7
      Johan Hedberg 提交于
      The mgmt.c file should be reserved purely for HCI_CHANNEL_CONTROL. The
      mgmt_control() function in it is already completely generic and has a
      single user in hci_sock.c. This patch moves the function there and
      renames it a bit more appropriately to hci_mgmt_cmd() (as it's a command
      dispatcher).
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      fa4335d7
    • J
      Bluetooth: Add hdev_init callback for HCI channels · 88b94ce9
      Johan Hedberg 提交于
      In order to make the mgmt command handling more generic we can't have a
      direct call to mgmt_init_hdev() from mgmt_control(). This patch adds a
      new callback to struct hci_mgmt_chan. And sets it to point to the
      mgmt_init_hdev() function for the HCI_CHANNEL_CONTROL instance.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      88b94ce9
    • J
      Bluetooth: Add generic mgmt helper API · a380b6cf
      Johan Hedberg 提交于
      There are several mgmt protocol features that will be needed by more
      than just the current HCI_CHANNEL_CONTROL. These include sending generic
      events as well as handling pending commands. This patch moves these
      functions out from mgmt.c to a new mgmt_util.c file.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      a380b6cf