- 30 Jul, 2020 1 commit
-
-
Marcel Holtmann authored
When using controller based address resolution, then the new address types 0x02 and 0x03 are used. These types need to be converted back into either public address or random address types. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Sathish Narsimman <sathish.narasimman@intel.com> Signed-off-by:
-
- 28 Jul, 2020 6 commits
-
-
Venkata Lakshmi Narayana Gubba authored
Setting memdump state to idle prior to setting of callback function pointer for command timeout to NULL,causing the issue.Now moved the initialisation of memdump state to qca_setup(). Fixes: d841502c ("Bluetooth: hci_qca: Collect controller memory dump during SSR") Signed-off-by:
Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org> Signed-off-by:
-
Abhishek Pandit-Subedi authored
Unregister from suspend notifications and cancel suspend preparations before running hci_dev_do_close. Otherwise, the suspend notifier may race with unregister and cause cmd_timeout even after hdev has been freed. Below is the trace from when this panic was seen: [ 832.578518] Bluetooth: hci_core.c:hci_cmd_timeout() hci0: command 0x0c05 tx timeout [ 832.586200] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 832.586203] #PF: supervisor read access in kernel mode [ 832.586205] #PF: error_code(0x0000) - not-present page [ 832.586206] PGD 0 P4D 0 [ 832.586210] PM: suspend exit [ 832.608870] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 832.613232] CPU: 3 PID: 10755 Comm: kworker/3:7 Not tainted 5.4.44-04894-g1e9dbb96a161 #1 [ 832.630036] Workqueue: events hci_cmd_timeout [bluetooth] [ 832.630046] RIP: 0010:__queue_work+0xf0/0x374 [ 832.630051] RSP: 0018:ffff9b5285f1fdf8 EFLAGS: 00010046 [ 832.674033] RAX: ffff8a97681bac00 RBX: 0000000000000000 RCX: ffff8a976a000600 [ 832.681162] RDX: 0000000000000000 RSI: 0000000000000009 RDI: ffff8a976a000748 [ 832.688289] RBP: ffff9b5285f1fe38 R08: 0000000000000000 R09: ffff8a97681bac00 [ 832.695418] R10: 0000000000000002 R11: ffff8a976a0006d8 R12: ffff8a9745107600 [ 832.698045] usb 1-6: new full-speed USB device number 119 using xhci_hcd [ 832.702547] R13: ffff8a9673658850 R14: 0000000000000040 R15: 000000000000001e [ 832.702549] FS: 0000000000000000(0000) GS:ffff8a976af80000(0000) knlGS:0000000000000000 [ 832.702550] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 832.702550] CR2: 0000000000000000 CR3: 000000010415a000 CR4: 00000000003406e0 [ 832.702551] Call Trace: [ 832.702558] queue_work_on+0x3f/0x68 [ 832.702562] process_one_work+0x1db/0x396 [ 832.747397] worker_thread+0x216/0x375 [ 832.751147] kthread+0x138/0x140 [ 832.754377] ? pr_cont_work+0x58/0x58 [ 832.758037] ? kthread_blkcg+0x2e/0x2e [ 832.761787] ret_from_fork+0x22/0x40 [ 832.846191] ---[ end trace fa93f466da517212 ]--- Fixes: 9952d90e ("Bluetooth: Handle PM_SUSPEND_PREPARE and PM_POST_SUSPEND") Signed-off-by:
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Reviewed-by:
Miao-chen Chou <mcchou@chromium.org> Signed-off-by:
-
Nicolas Boichat authored
We should not call hci_unregister_dev if the device was not successfully registered. Fixes: c34dc3bf ("Bluetooth: hci_serdev: Introduce hci_uart_unregister_device()") Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Signed-off-by:
-
Max Chou authored
The original return is NOTIFY_STOP, but notifier_call_chain would stop the future call for register_pm_notifier even registered on other Kernel modules with the same priority which value is zero. Signed-off-by:
Max Chou <max.chou@realtek.com> Signed-off-by:
-
Nicolas Boichat authored
HCI_UART_RESET_ON_INIT belongs in hdev_flags, not flags. Fixes: ce945552 ("Bluetooth: hci_h5: Add support for serdev enumerated devices") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Ismael Ferreras Morezuelas authored
For some reason they tend to squat on the very first CSR/ Cambridge Silicon Radio VID/PID instead of paying fees. This is an extremely common problem; the issue goes as back as 2013 and these devices are only getting more popular, even rebranded by reputable vendors and sold by retailers everywhere. So, at this point in time there are hundreds of modern dongles reusing the ID of what originally was an early Bluetooth 1.1 controller. Linux is the only place where they don't work due to spotty checks in our detection code. It only covered a minimum subset. So what's the big idea? Take advantage of the fact that all CSR chips report the same internal version as both the LMP sub-version and HCI revision number. It always matches, couple that with the manufacturer code, that rarely lies, and we now have a good idea of who is who. Additionally, by compiling a list of user-reported HCI/lsusb dumps, and searching around for legit CSR dongles in similar product ranges we can find what CSR BlueCore firmware supported which Bluetooth versions. That way we can narrow down ranges of fakes for each of them. e.g. Real CSR dongles with LMP subversion 0x73 are old enough that support BT 1.1 only; so it's a dead giveaway when some third-party BT 4.0 dongle reuses it. So, to sum things up; there are multiple classes of fake controllers reusing the same 0A12:0001 VID/PID. This has been broken for a while. Known 'fake' bcdDevices: 0x0100, 0x0134, 0x1915, 0x2520, 0x7558, 0x8891 IC markings on 0x7558: FR3191AHAL 749H15143 (???) https://bugzilla.kernel.org/show_bug.cgi?id=60824 Fixes: 81cac64b (Deal with USB devices that are faking CSR vendor) Reported-by:Michał Wiśniewski <brylozketrzyn@gmail.com> Tested-by:
Mike Johnson <yuyuyak@gmail.com> Tested-by:
Ricardo Rodrigues <ekatonb@gmail.com> Tested-by:
M.Hanny Sabbagh <mhsabbagh@outlook.com> Tested-by:
Oussama BEN BRAHIM <b.brahim.oussama@gmail.com> Tested-by:
Ismael Ferreras Morezuelas <swyterzone@gmail.com> Signed-off-by:
-
- 16 Jul, 2020 1 commit
-
-
Patrick Steinhardt authored
Starting with the upgrade to v5.8-rc3, I've noticed I wasn't able to connect to my Bluetooth headset properly anymore. While connecting to the device would eventually succeed, bluetoothd seemed to be confused about the current connection state where the state was flapping hence and forth. Bisecting this issue led to commit 3ca44c16 (Bluetooth: Consolidate encryption handling in hci_encrypt_cfm, 2020-05-19), which refactored `hci_encrypt_cfm` to also handle updating the connection state. The commit in question changed the code to call `hci_connect_cfm` inside `hci_encrypt_cfm` and to change the connection state. But with the conversion, we now only update the connection state if a status was set already. In fact, the reverse should be true: the status should be updated if no status is yet set. So let's fix the isuse by reversing the condition. Fixes: 3ca44c16 ("Bluetooth: Consolidate encryption handling in hci_encrypt_cfm") Signed-off-by:
Patrick Steinhardt <ps@pks.im> Acked-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
-
- 15 Jul, 2020 1 commit
-
-
Daniel Winkler authored
Add functionality to disable and remove advertising instances, and use that functionality in MGMT add/remove advertising calls. Currently, advertising is globally-disabled, i.e. all instances are disabled together, even if hardware offloading is available. This patch adds functionality to disable and remove individual adv instances, solving two issues: 1. On new advertisement registration, a global disable was done, and then only the new instance was enabled. This meant only the newest instance was actually enabled. 2. On advertisement removal, the structure was removed, but the instance was never disabled or removed, which is incorrect with hardware offload support. Signed-off-by:
Daniel Winkler <danielwinkler@google.com> Reviewed-by:
Shyh-In Hwang <josephsih@chromium.org> Reviewed-by:
Alain Michaud <alainm@chromium.org> Signed-off-by:
-
- 13 Jul, 2020 4 commits
-
-
Peilin Ye authored
Check `num_rsp` before using it as for-loop counter. Add `unlock` label. Cc: stable@vger.kernel.org Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
-
Peilin Ye authored
Check `num_rsp` before using it as for-loop counter. Cc: stable@vger.kernel.org Signed-off-by:
-
Venkata Lakshmi Narayana Gubba authored
1.During SSR for command time out if BT SoC goes to inresponsive state, power cycling of BT SoC was not happening. Given the fix by sending hw error event to reset the BT SoC. 2.If SSR is triggered then ignore the transmit data requests to BT SoC until SSR is completed. Signed-off-by:
-
Joseph Hwang authored
This patch adds the Realtek 8822CE controller to the usb_device_id table to support the wideband speech capability. Signed-off-by:
-
- 10 Jul, 2020 5 commits
-
-
Alexander A. Klimov authored
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by:Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by:
-
Gustavo A. R. Silva authored
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
-
Gustavo A. R. Silva authored
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by:
-
Peilin Ye authored
Check upon `num_rsp` is insufficient. A malformed event packet with a large `num_rsp` number makes hci_extended_inquiry_result_evt() go out of bounds. Fix it. This patch fixes the following syzbot bug: https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2 Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by:Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
- 08 Jul, 2020 1 commit
-
-
Miao-chen Chou authored
Even with one advertisement monitor in place, the scan policy should use the whitelist while the system is going to suspend to prevent waking by random advertisement. The following test was performed. - With a paired device, register one advertisement monitor, suspend the system and verify that the host was not awaken by random advertisements. Signed-off-by:
-
- 07 Jul, 2020 6 commits
-
-
Alain Michaud authored
This patch adds an le_simult_central_peripheral features which allows a clients to determine if the controller is able to support peripheral and central connections separately and at the same time. Signed-off-by:
-
Miao-chen Chou authored
This fixes the kernel oops by removing unnecessary background scan update from hci_adv_monitors_clear() which shouldn't invoke any work queue. The following test was performed. - Run "rmmod btusb" and verify that no kernel oops is triggered. Signed-off-by:
-
Hilda Wu authored
RTL8822CE supports transparent WBS to apply USB alternate setting 1. Add a flag to the device match data to apply alternate setting 1 which meet the transfer speed for WBS support. Signed-off-by:
Hilda Wu <hildawu@realtek.com> Signed-off-by:
-
Alain Michaud authored
This patch fixes active scans to use the configured default parameters. Signed-off-by:
-
Alain Michaud authored
This patch adds a configurable LE autoconnect timeout. Signed-off-by:
-
Martin Blumenstingl authored
uart-has-rtscts is a boolean property. These are defined as present (which means that this property evaluates to "true") or absent (which means that this property evaluates to "false"). Remove the numeric value from the example to make it comply with the boolean property bindings. Fixes: 1cc2d0e0 ("dt-bindings: net: bluetooth: Add rtl8723bs-bluetooth") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
- 26 Jun, 2020 1 commit
-
-
Abhishek Pandit-Subedi authored
Add a comment clarifying that a PM reference in btusb_qca_cmd_timeout is not unbalanced because it results in a device reset. Signed-off-by:
-
- 25 Jun, 2020 1 commit
-
-
Kiran K authored
Address the scalability to support new generation Intel controller with respect to readability and enhancement to new firmware download sequence Signed-off-by:
Kiran K <kiran.k@intel.com> Reviewed-by:
Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by:
-
- 24 Jun, 2020 3 commits
-
-
Abhishek Pandit-Subedi authored
When restarting LE scanning, check if it's currently paused before enabling passive scanning. Signed-off-by:
-
Abhishek Pandit-Subedi authored
When the BTUSB_WAKEUP_DISABLE flag is set, always return true for prevent wake. This tells the suspend notifier not to prepare the controller for reconnections during suspend. Signed-off-by:
-
Abhishek Pandit-Subedi authored
QCA_ROME sometimes gets into a state where it is unresponsive to commands. Since it doesn't have support for a reset gpio, reset the usb port when this occurs instead. Signed-off-by:
-
- 23 Jun, 2020 3 commits
-
-
Sean Wang authored
Data RAM on the device have to be powered on before starting to download the firmware. Fixes: 9aebfd4a ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Co-developed-by:
Mark Chen <Mark-YW.Chen@mediatek.com> Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Sean Wang authored
Data RAM on the device have to be powered on before starting to download the firmware. Fixes: a1c49c43 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Co-developed-by:
-
Lihong Kou authored
In the case we set or free the global value listen_chan in different threads, we can encounter the UAF problems because the method is not protected by any lock, add one to avoid this bug. BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 Read of size 8 at addr ffff888096950000 by task kworker/1:102/2868 CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events do_enable_set Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446 chan_create net/bluetooth/6lowpan.c:640 [inline] bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline] do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498 do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff888096950000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 0 bytes inside of 2048-byte region [ffff888096950000, ffff888096950800) The buggy address belongs to the page: page:ffffea00025a5400 refcount:1 mapcount:0 mapping:ffff8880aa400e00 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00 raw: 0000000000000000 ffff888096950000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com Signed-off-by:Lihong Kou <koulihong@huawei.com> Signed-off-by:
-
- 22 Jun, 2020 3 commits
-
-
Luiz Augusto von Dentz authored
E0 is not allowed with Level 4: BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C page 1319: '128-bit equivalent strength for link and encryption keys required using FIPS approved algorithms (E0 not allowed, SAFER+ not allowed, and P-192 not allowed; encryption key not shortened' SC enabled: > HCI Event: Read Remote Extended Features (0x23) plen 13 Status: Success (0x00) Handle: 256 Page: 1/2 Features: 0x0b 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) Secure Connections (Host Support) > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 256 Encryption: Enabled with AES-CCM (0x02) SC disabled: > HCI Event: Read Remote Extended Features (0x23) plen 13 Status: Success (0x00) Handle: 256 Page: 1/2 Features: 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Secure Simple Pairing (Host Support) LE Supported (Host) > HCI Event: Encryption Change (0x08) plen 4 Status: Success (0x00) Handle: 256 Encryption: Enabled with E0 (0x01) [May 8 20:23] Bluetooth: hci0: Invalid security: expect AES but E0 was used < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 256 Reason: Authentication Failure (0x05) Signed-off-by: -
Alain Michaud authored
When the extended advertisement feature is enabled, a hardcoded min and max interval of 0x8000 is used. This patch fixes this issue by using the configured min/max value. This was validated by setting min/max in main.conf and making sure the right setting is applied: < HCI Command: LE Set Extended Advertising Parameters (0x08|0x0036) plen 25 #93 [hci0] 10.953011 … Min advertising interval: 181.250 msec (0x0122) Max advertising interval: 181.250 msec (0x0122) … Signed-off-by:
-
Abhishek Pandit-Subedi authored
Adding hci_dev_lock since hci_conn_params_(lookup|add) require this lock. Suggested-by:
-
- 18 Jun, 2020 4 commits
-
-
Marcel Holtmann authored
The command status reply is only for failure. When completing set system config command, the reply has to be command complete. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Manish Mandlik authored
If user decides to cancel the ongoing pairing process (e.g. by clicking the cancel button on pairing/passkey window), abort any ongoing pairing and then terminate the link if it was created because of the pair device action. Signed-off-by:
Manish Mandlik <mmandlik@google.com> Signed-off-by:
-
Miao-chen Chou authored
This calls hci_update_background_scan() when there is any update on the advertisement monitors. If there is at least one advertisement monitor, the filtering policy of scan parameters should be 0x00. This also reports device found mgmt events if there is at least one monitor. The following cases were tested with btmgmt advmon-* commands. (1) add a ADV monitor and observe that the passive scanning is triggered. (2) remove the last ADV monitor and observe that the passive scanning is terminated. (3) with a LE peripheral paired, repeat (1) and observe the passive scanning continues. (4) with a LE peripheral paired, repeat (2) and observe the passive scanning continues. (5) with a ADV monitor, suspend/resume the host and observe the passive scanning continues. Signed-off-by:
-
Miao-chen Chou authored
This notifies management sockets on MGMT_EV_ADV_MONITOR_REMOVED event. The following test was performed. - Start two btmgmt consoles, issue a btmgmt advmon-remove command on one console and observe a MGMT_EV_ADV_MONITOR_REMOVED event on the other. Signed-off-by:
-
