1. 12 6月, 2013 6 次提交
    • L
      rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1) networks · 5b8df24e
      Larry Finger 提交于
      Driver rtl8192cu can connect to WPA2 networks, but fails for any other
      encryption method. The cause is a failure to set the rate control data
      blocks. These changes fix https://bugzilla.redhat.com/show_bug.cgi?id=952793
      and https://bugzilla.redhat.com/show_bug.cgi?id=761525.
      Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5b8df24e
    • M
      mwifiex: debugfs: Fix out of bounds array access · f873ded2
      Mark A. Greer 提交于
      When reading the contents of '/sys/kernel/debug/mwifiex/p2p0/info',
      the following panic occurs:
      
      $ cat /sys/kernel/debug/mwifiex/p2p0/info
      Unable to handle kernel paging request at virtual address 74706164
      pgd = de530000
      [74706164] *pgd=00000000
      Internal error: Oops: 5 [#1] SMP ARM
      Modules linked in: phy_twl4030_usb omap2430 musb_hdrc mwifiex_sdio mwifiex
      CPU: 0 PID: 1635 Comm: cat Not tainted 3.10.0-rc1-00010-g1268390 #1
      task: de16b6c0 ti: de048000 task.ti: de048000
      PC is at strnlen+0xc/0x4c
      LR is at string+0x3c/0xf8
      pc : [<c02c123c>]    lr : [<c02c2d1c>]    psr: a0000013
      sp : de049e10  ip : c06efba0  fp : de6d2092
      r10: bf01a260  r9 : ffffffff  r8 : 74706164
      r7 : 0000ffff  r6 : ffffffff  r5 : de6d209c  r4 : 00000000
      r3 : ff0a0004  r2 : 74706164  r1 : ffffffff  r0 : 74706164
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 10c5387d  Table: 9e530019  DAC: 00000015
      Process cat (pid: 1635, stack limit = 0xde048240)
      Stack: (0xde049e10 to 0xde04a000)
      9e00:                                     de6d2092 00000002 bf01a25e de6d209c
      9e20: de049e80 c02c438c 0000000a ff0a0004 ffffffff 00000000 00000000 de049e48
      9e40: 00000000 2192df6d ff0a0004 ffffffff 00000000 de6d2092 de049ef8 bef3cc00
      9e60: de6b0000 dc358000 de6d2000 00000000 00000003 c02c45a4 bf01790c bf01a254
      9e80: 74706164 bf018698 00000000 de59c3c0 de048000 de049f80 00001000 bef3cc00
      9ea0: 00000008 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      9ee0: 00000000 00000000 00000000 00000001 00000000 00000000 6669776d 20786569
      9f00: 20302e31 2e343128 392e3636 3231702e 00202933 00000000 00000003 c0294898
      9f20: 00000000 00000000 00000000 00000000 de59c3c0 c0107c04 de554000 de59c3c0
      9f40: 00001000 bef3cc00 de049f80 bef3cc00 de049f80 00000000 00000003 c0108a00
      9f60: de048000 de59c3c0 00000000 00000000 de59c3c0 00001000 bef3cc00 c0108b60
      9f80: 00000000 00000000 00001000 bef3cc00 00000003 00000003 c0014128 de048000
      9fa0: 00000000 c0013f80 00001000 bef3cc00 00000003 bef3cc00 00001000 00000000
      9fc0: 00001000 bef3cc00 00000003 00000003 00000001 00000001 00000001 00000003
      9fe0: 00000000 bef3cbdc 00011984 b6f1127c 60000010 00000003 18dbdd2c 7f7bfffd
      [<c02c123c>] (strnlen+0xc/0x4c) from [<c02c2d1c>] (string+0x3c/0xf8)
      [<c02c2d1c>] (string+0x3c/0xf8) from [<c02c438c>] (vsnprintf+0x1e8/0x3e8)
      [<c02c438c>] (vsnprintf+0x1e8/0x3e8) from [<c02c45a4>] (sprintf+0x18/0x24)
      [<c02c45a4>] (sprintf+0x18/0x24) from [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex])
      [<bf01790c>] (mwifiex_info_read+0xfc/0x3e8 [mwifiex]) from [<c0108a00>] (vfs_read+0xb0/0x144)
      [<c0108a00>] (vfs_read+0xb0/0x144) from [<c0108b60>] (SyS_read+0x44/0x70)
      [<c0108b60>] (SyS_read+0x44/0x70) from [<c0013f80>] (ret_fast_syscall+0x0/0x30)
      Code: e12fff1e e3510000 e1a02000 0a00000d (e5d03000)
      ---[ end trace ca98273dc605a04f ]---
      
      The panic is caused by the mwifiex_info_read() routine assuming that
      there can only be four modes (0-3) which is an invalid assumption.
      For example, when testing P2P, the mode is '8' (P2P_CLIENT) so the
      code accesses data beyond the bounds of the bss_modes[] array which
      causes the panic.  Fix this by updating bss_modes[] to support the
      current list of modes and adding a check to prevent the out-of-bounds
      access from occuring in the future when more modes are added.
      Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
      Acked-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f873ded2
    • J
      Bluetooth: Fix mgmt handling of power on failures · 96570ffc
      Johan Hedberg 提交于
      If hci_dev_open fails we need to ensure that the corresponding
      mgmt_set_powered command gets an appropriate response. This patch fixes
      the missing response by adding a new mgmt_set_powered_failed function
      that's used to indicate a power on failure to mgmt. Since a situation
      with the device being rfkilled may require special handling in user
      space the patch uses a new dedicated mgmt status code for this.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      96570ffc
    • J
      Bluetooth: Fix missing length checks for L2CAP signalling PDUs · cb3b3152
      Johan Hedberg 提交于
      There has been code in place to check that the L2CAP length header
      matches the amount of data received, but many PDU handlers have not been
      checking that the data received actually matches that expected by the
      specific PDU. This patch adds passing the length header to the specific
      handler functions and ensures that those functions fail cleanly in the
      case of an incorrect amount of data.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cb3b3152
    • B
      Bluetooth: btmrvl: support Marvell Bluetooth device SD8897 · 22f2efed
      Bing Zhao 提交于
      The register offsets have been changed in SD8897 and newer chips.
      Define a new btmrvl_sdio_card_reg map for SD88xx.
      Signed-off-by: NBing Zhao <bzhao@marvell.com>
      Signed-off-by: NFrank Huang <frankh@marvell.com>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      22f2efed
    • J
      Bluetooth: Fix checks for LE support on LE-only controllers · 757aee0f
      Johan Hedberg 提交于
      LE-only controllers do not support extended features so any kind of host
      feature bit checks do not make sense for them. This patch fixes code
      used for both single-mode (LE-only) and dual-mode (BR/EDR/LE) to use the
      HCI_LE_ENABLED flag instead of the "Host LE supported" feature bit for
      LE support tests.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Acked-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      757aee0f
  2. 29 5月, 2013 10 次提交
  3. 27 5月, 2013 4 次提交
  4. 25 5月, 2013 3 次提交
  5. 24 5月, 2013 3 次提交
  6. 23 5月, 2013 3 次提交
  7. 21 5月, 2013 4 次提交
  8. 18 5月, 2013 7 次提交