1. 12 4月, 2014 1 次提交
    • D
      net: Fix use after free by removing length arg from sk_data_ready callbacks. · 676d2369
      David S. Miller 提交于
      Several spots in the kernel perform a sequence like:
      
      	skb_queue_tail(&sk->s_receive_queue, skb);
      	sk->sk_data_ready(sk, skb->len);
      
      But at the moment we place the SKB onto the socket receive queue it
      can be consumed and freed up.  So this skb->len access is potentially
      to freed up memory.
      
      Furthermore, the skb->len can be modified by the consumer so it is
      possible that the value isn't accurate.
      
      And finally, no actual implementation of this callback actually uses
      the length argument.  And since nobody actually cared about it's
      value, lots of call sites pass arbitrary values in such as '0' and
      even '1'.
      
      So just remove the length argument from the callback, that way there
      is no confusion whatsoever and all of these use-after-free cases get
      fixed as a side effect.
      
      Based upon a patch by Eric Dumazet and his suggestion to audit this
      issue tree-wide.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      676d2369
  2. 27 3月, 2014 1 次提交
  3. 13 3月, 2014 1 次提交
  4. 15 2月, 2014 1 次提交
  5. 13 2月, 2014 6 次提交
  6. 19 1月, 2014 1 次提交
  7. 07 1月, 2014 1 次提交
    • J
      Bluetooth: Default to no security with L2CAP RAW sockets · cb6ca8e1
      Johan Hedberg 提交于
      L2CAP RAW sockets can be used for things which do not involve
      establishing actual connection oriented L2CAP channels. One example of
      such usage is the l2ping tool. The default security level for L2CAP
      sockets is LOW, which implies that for SSP based connection
      authentication is still requested (although with no MITM requirement),
      which is not what we want (or need) for things like l2ping. Therefore,
      default to one lower level, i.e. BT_SECURITY_SDP, for L2CAP RAW sockets
      in order not to trigger unwanted authentication requests.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      cb6ca8e1
  8. 05 12月, 2013 8 次提交
  9. 22 10月, 2013 5 次提交
  10. 18 10月, 2013 1 次提交
  11. 17 10月, 2013 1 次提交
  12. 16 10月, 2013 5 次提交
  13. 15 10月, 2013 2 次提交
  14. 14 10月, 2013 4 次提交
  15. 13 10月, 2013 2 次提交
    • M
      Bluetooth: Return the correct address type for L2CAP sockets · 4f1654e0
      Marcel Holtmann 提交于
      The L2CAP sockets can use BR/EDR public, LE public and LE random
      addresses for various combinations of source and destination
      devices. So make sure that getsockname(), getpeername() and
      accept() return the correct address type.
      
      For this the address type of the source and destination is stored
      with the L2CAP channel information. The stored address type is
      not the one specific for the HCI protocol. It is the address
      type used for the L2CAP sockets and the management interface.
      
      The underlying HCI connections store the HCI address type. If
      needed, it gets converted to the socket address type.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      4f1654e0
    • M
      Bluetooth: Store address information in L2CAP channel structure · 7eafc59e
      Marcel Holtmann 提交于
      With the effort of abstracting the L2CAP socket from the underlying
      L2CAP channel it is important to store the source and destination
      address information directly in the L2CAP channel structure.
      
      Direct access to the HCI connection address information is not
      possible since they might not be avaiable at L2CAP channel
      creation time. The address information will be updated when
      the underlying BR/EDR or LE connection status changes.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      7eafc59e