05 Nov, 2020

6 commits


08 Oct, 2020

1 commit

  • * tag 'v5.4.70': (3051 commits)
    Linux 5.4.70
    netfilter: ctnetlink: add a range check for l3/l4 protonum
    ep_create_wakeup_source(): dentry name can change under you...
    ...

    Conflicts:
    arch/arm/mach-imx/pm-imx6.c
    arch/arm64/boot/dts/freescale/imx8mm-evk.dts
    arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
    drivers/crypto/caam/caamalg.c
    drivers/gpu/drm/imx/dw_hdmi-imx.c
    drivers/gpu/drm/imx/imx-ldb.c
    drivers/gpu/drm/imx/ipuv3/ipuv3-crtc.c
    drivers/mmc/host/sdhci-esdhc-imx.c
    drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
    drivers/net/ethernet/freescale/enetc/enetc.c
    drivers/net/ethernet/freescale/enetc/enetc_pf.c
    drivers/thermal/imx_thermal.c
    drivers/usb/cdns3/ep0.c
    drivers/xen/swiotlb-xen.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c

    Signed-off-by: Jason Liu

    Jason Liu
     

01 Oct, 2020

5 commits

  • [ Upstream commit adf1d6926444029396861413aba8a0f2a805742a ]

    After sending Inquiry Cancel command to the controller, it is possible
    that Inquiry Complete event comes before Inquiry Cancel command complete
    event. In this case the Inquiry Cancel command will have status of
    Command Disallowed since there is no Inquiry session to be cancelled.
    This case should not be treated as error, otherwise we can reach an
    inconsistent state.

    Example of a btmon trace when this happened:

    < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0
    > HCI Event: Inquiry Complete (0x01) plen 1
    Status: Success (0x00)
    > HCI Event: Command Complete (0x0e) plen 4
    Inquiry Cancel (0x01|0x0002) ncmd 1
    Status: Command Disallowed (0x0c)

    Signed-off-by: Sonny Sasaka
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Sonny Sasaka
     
  • [ Upstream commit 96298f640104e4cd9a913a6e50b0b981829b94ff ]

    According to Core Spec Version 5.2 | Vol 3, Part A 6.1.5,
    the incoming L2CAP_ConfigReq should be handled during
    OPEN state.

    The section below shows the btmon trace when running
    L2CAP/COS/CFD/BV-12-C before and after this change.

    === Before ===
    ...
    > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22
    L2CAP: Connection Request (0x02) ident 2 len 4
    PSM: 1 (0x0001)
    Source CID: 65
    < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23
    L2CAP: Connection Response (0x03) ident 2 len 8
    Destination CID: 64
    Source CID: 65
    Result: Connection successful (0x0000)
    Status: No further information available (0x0000)
    < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24
    L2CAP: Configure Request (0x04) ident 2 len 4
    Destination CID: 65
    Flags: 0x0000
    > HCI Event: Number of Completed Packets (0x13) plen 5 #25
    Num handles: 1
    Handle: 256
    Count: 1
    > HCI Event: Number of Completed Packets (0x13) plen 5 #26
    Num handles: 1
    Handle: 256
    Count: 1
    > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27
    L2CAP: Configure Request (0x04) ident 3 len 8
    Destination CID: 64
    Flags: 0x0000
    Option: Unknown (0x10) [hint]
    01 00 ..
    < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28
    L2CAP: Configure Response (0x05) ident 3 len 10
    Source CID: 65
    Flags: 0x0000
    Result: Success (0x0000)
    Option: Maximum Transmission Unit (0x01) [mandatory]
    MTU: 672
    > HCI Event: Number of Completed Packets (0x13) plen 5 #29
    Num handles: 1
    Handle: 256
    Count: 1
    > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30
    L2CAP: Configure Response (0x05) ident 2 len 6
    Source CID: 64
    Flags: 0x0000
    Result: Success (0x0000)
    > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31
    L2CAP: Configure Request (0x04) ident 3 len 12
    Destination CID: 64
    Flags: 0x0000
    Option: Unknown (0x10) [hint]
    01 00 91 02 11 11 ......
    < ACL Data TX: Handle 256 flags 0x00 dlen 14 #32
    L2CAP: Command Reject (0x01) ident 3 len 6
    Reason: Invalid CID in request (0x0002)
    Destination CID: 64
    Source CID: 65
    > HCI Event: Number of Completed Packets (0x13) plen 5 #33
    Num handles: 1
    Handle: 256
    Count: 1
    ...
    === After ===
    ...
    > ACL Data RX: Handle 256 flags 0x02 dlen 12 #22
    L2CAP: Connection Request (0x02) ident 2 len 4
    PSM: 1 (0x0001)
    Source CID: 65
    < ACL Data TX: Handle 256 flags 0x00 dlen 16 #23
    L2CAP: Connection Response (0x03) ident 2 len 8
    Destination CID: 64
    Source CID: 65
    Result: Connection successful (0x0000)
    Status: No further information available (0x0000)
    < ACL Data TX: Handle 256 flags 0x00 dlen 12 #24
    L2CAP: Configure Request (0x04) ident 2 len 4
    Destination CID: 65
    Flags: 0x0000
    > HCI Event: Number of Completed Packets (0x13) plen 5 #25
    Num handles: 1
    Handle: 256
    Count: 1
    > HCI Event: Number of Completed Packets (0x13) plen 5 #26
    Num handles: 1
    Handle: 256
    Count: 1
    > ACL Data RX: Handle 256 flags 0x02 dlen 16 #27
    L2CAP: Configure Request (0x04) ident 3 len 8
    Destination CID: 64
    Flags: 0x0000
    Option: Unknown (0x10) [hint]
    01 00 ..
    < ACL Data TX: Handle 256 flags 0x00 dlen 18 #28
    L2CAP: Configure Response (0x05) ident 3 len 10
    Source CID: 65
    Flags: 0x0000
    Result: Success (0x0000)
    Option: Maximum Transmission Unit (0x01) [mandatory]
    MTU: 672
    > HCI Event: Number of Completed Packets (0x13) plen 5 #29
    Num handles: 1
    Handle: 256
    Count: 1
    > ACL Data RX: Handle 256 flags 0x02 dlen 14 #30
    L2CAP: Configure Response (0x05) ident 2 len 6
    Source CID: 64
    Flags: 0x0000
    Result: Success (0x0000)
    > ACL Data RX: Handle 256 flags 0x02 dlen 20 #31
    L2CAP: Configure Request (0x04) ident 3 len 12
    Destination CID: 64
    Flags: 0x0000
    Option: Unknown (0x10) [hint]
    01 00 91 02 11 11 .....
    < ACL Data TX: Handle 256 flags 0x00 dlen 18 #32
    L2CAP: Configure Response (0x05) ident 3 len 10
    Source CID: 65
    Flags: 0x0000
    Result: Success (0x0000)
    Option: Maximum Transmission Unit (0x01) [mandatory]
    MTU: 672
    < ACL Data TX: Handle 256 flags 0x00 dlen 12 #33
    L2CAP: Configure Request (0x04) ident 3 len 4
    Destination CID: 65
    Flags: 0x0000
    > HCI Event: Number of Completed Packets (0x13) plen 5 #34
    Num handles: 1
    Handle: 256
    Count: 1
    > HCI Event: Number of Completed Packets (0x13) plen 5 #35
    Num handles: 1
    Handle: 256
    Count: 1
    ...

    Signed-off-by: Howard Chung
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Howard Chung
     
  • [ Upstream commit 08bb4da90150e2a225f35e0f642cdc463958d696 ]

    Some controllers have been observed to send zero'd events under some
    conditions. This change guards against this condition as well as adding
    a trace to facilitate diagnosability of this condition.

    Signed-off-by: Alain Michaud
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Alain Michaud
     
  • [ Upstream commit 2a154903cec20fb64ff4d7d617ca53c16f8fd53a ]

    Prefetch channel before killing sock in order to fix UAF like

    BUG: KASAN: use-after-free in l2cap_sock_release+0x24c/0x290 net/bluetooth/l2cap_sock.c:1212
    Read of size 8 at addr ffff8880944904a0 by task syz-fuzzer/9751

    Reported-by: syzbot+c3c5bdea7863886115dc@syzkaller.appspotmail.com
    Fixes: 6c08fc896b60 ("Bluetooth: Fix refcount use-after-free issue")
    Cc: Manish Mandlik
    Signed-off-by: Hillf Danton
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Hillf Danton
     
  • [ Upstream commit 6c08fc896b60893c5d673764b0668015d76df462 ]

    There is no lock preventing both l2cap_sock_release() and
    chan->ops->close() from running at the same time.

    If we consider Thread A running l2cap_chan_timeout() and Thread B running
    l2cap_sock_release(), expected behavior is:
    A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
    A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()
    B::l2cap_sock_release()->sock_orphan()
    B::l2cap_sock_release()->l2cap_sock_kill()

    where,
    sock_orphan() clears "sk->sk_socket" and l2cap_sock_teardown_cb() marks
    socket as SOCK_ZAPPED.

    In l2cap_sock_kill(), there is an "if-statement" that checks if both
    sock_orphan() and sock_teardown() has been run i.e. sk->sk_socket is NULL
    and socket is marked as SOCK_ZAPPED. Socket is killed if the condition is
    satisfied.

    In the race condition, following occurs:
    A::l2cap_chan_timeout()->l2cap_chan_close()->l2cap_sock_teardown_cb()
    B::l2cap_sock_release()->sock_orphan()
    B::l2cap_sock_release()->l2cap_sock_kill()
    A::l2cap_chan_timeout()->l2cap_sock_close_cb()->l2cap_sock_kill()

    In this scenario, "if-statement" is true in both B::l2cap_sock_kill() and
    A::l2cap_sock_kill() and we hit "refcount: underflow; use-after-free" bug.

    Similar condition occurs at other places where teardown/sock_kill is
    happening:
    l2cap_disconnect_rsp()->l2cap_chan_del()->l2cap_sock_teardown_cb()
    l2cap_disconnect_rsp()->l2cap_sock_close_cb()->l2cap_sock_kill()

    l2cap_conn_del()->l2cap_chan_del()->l2cap_sock_teardown_cb()
    l2cap_conn_del()->l2cap_sock_close_cb()->l2cap_sock_kill()

    l2cap_disconnect_req()->l2cap_chan_del()->l2cap_sock_teardown_cb()
    l2cap_disconnect_req()->l2cap_sock_close_cb()->l2cap_sock_kill()

    l2cap_sock_cleanup_listen()->l2cap_chan_close()->l2cap_sock_teardown_cb()
    l2cap_sock_cleanup_listen()->l2cap_sock_kill()

    Protect teardown/sock_kill and orphan/sock_kill by adding hold_lock on
    l2cap channel to ensure that the socket is killed only after marked as
    zapped and orphan.

    Signed-off-by: Manish Mandlik
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Manish Mandlik
     

19 Aug, 2020

1 commit

  • [ Upstream commit f9c70bdc279b191da8d60777c627702c06e4a37d ]

    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
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Lihong Kou
     

11 Aug, 2020

3 commits


05 Aug, 2020

1 commit

  • [ Upstream commit a2ec905d1e160a33b2e210e45ad30445ef26ce0e ]

    Fix kernel oops observed when an ext adv data is larger than 31 bytes.

    This can be reproduced by setting up an advertiser with advertisement
    larger than 31 bytes. The issue is not sensitive to the advertisement
    content. In particular, this was reproduced with an advertisement of
    229 bytes filled with 'A'. See stack trace below.

    This is fixed by not catching ext_adv as legacy adv are only cached to
    be able to concatenate a scanable adv with its scan response before
    sending it up through mgmt.

    With ext_adv, this is no longer necessary.

    general protection fault: 0000 [#1] SMP PTI
    CPU: 6 PID: 205 Comm: kworker/u17:0 Not tainted 5.4.0-37-generic #41-Ubuntu
    Hardware name: Dell Inc. XPS 15 7590/0CF6RR, BIOS 1.7.0 05/11/2020
    Workqueue: hci0 hci_rx_work [bluetooth]
    RIP: 0010:hci_bdaddr_list_lookup+0x1e/0x40 [bluetooth]
    Code: ff ff e9 26 ff ff ff 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 07 48 89 e5 48 39 c7 75 0a eb 24 48 8b 00 48 39 f8 74 1c 44 8b 06 39 40 10 75 ef 44 0f b7 4e 04 66 44 39 48 14 75 e3 38 50 16 75
    RSP: 0018:ffffbc6a40493c70 EFLAGS: 00010286
    RAX: 4141414141414141 RBX: 000000000000001b RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff9903e76c100f RDI: ffff9904289d4b28
    RBP: ffffbc6a40493c70 R08: 0000000093570362 R09: 0000000000000000
    R10: 0000000000000000 R11: ffff9904344eae38 R12: ffff9904289d4000
    R13: 0000000000000000 R14: 00000000ffffffa3 R15: ffff9903e76c100f
    FS: 0000000000000000(0000) GS:ffff990434580000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007feed125a000 CR3: 00000001b860a003 CR4: 00000000003606e0
    Call Trace:
    process_adv_report+0x12e/0x560 [bluetooth]
    hci_le_meta_evt+0x7b2/0xba0 [bluetooth]
    hci_event_packet+0x1c29/0x2a90 [bluetooth]
    hci_rx_work+0x19b/0x360 [bluetooth]
    process_one_work+0x1eb/0x3b0
    worker_thread+0x4d/0x400
    kthread+0x104/0x140

    Fixes: c215e9397b00 ("Bluetooth: Process extended ADV report event")
    Reported-by: Andy Nguyen
    Reported-by: Linus Torvalds
    Reported-by: Balakrishna Godavarthi
    Signed-off-by: Alain Michaud
    Tested-by: Sonny Sasaka
    Acked-by: Marcel Holtmann
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sasha Levin

    Alain Michaud
     

16 Jul, 2020

1 commit


22 Jun, 2020

1 commit

  • [ Upstream commit 56b5453a86203a44726f523b4133c1feca49ce7c ]

    Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection
    with invalid parameter at the first SCO request expecting AG to
    attempt another SCO request with the use of "safe settings" for
    given codec, base on section 5.7.1.2 of HFP 1.7 specification.

    This patch addresses it by adding "Invalid LMP Parameters" (0x1e)
    to the SCO fallback case. Verified with below log:

    < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
    Handle: 256
    Transmit bandwidth: 8000
    Receive bandwidth: 8000
    Max latency: 13
    Setting: 0x0003
    Input Coding: Linear
    Input Data Format: 1's complement
    Input Sample Size: 8-bit
    # of bits padding at MSB: 0
    Air Coding Format: Transparent Data
    Retransmission effort: Optimize for link quality (0x02)
    Packet type: 0x0380
    3-EV3 may not be used
    2-EV5 may not be used
    3-EV5 may not be used
    > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) ncmd 1
    Status: Success (0x00)
    > HCI Event: Number of Completed Packets (0x13) plen 5
    Num handles: 1
    Handle: 256
    Count: 1
    > HCI Event: Max Slots Change (0x1b) plen 3
    Handle: 256
    Max slots: 1
    > HCI Event: Synchronous Connect Complete (0x2c) plen 17
    Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
    Handle: 0
    Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
    Link type: eSCO (0x02)
    Transmission interval: 0x00
    Retransmission window: 0x02
    RX packet length: 0
    TX packet length: 0
    Air mode: Transparent (0x03)
    < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
    Handle: 256
    Transmit bandwidth: 8000
    Receive bandwidth: 8000
    Max latency: 8
    Setting: 0x0003
    Input Coding: Linear
    Input Data Format: 1's complement
    Input Sample Size: 8-bit
    # of bits padding at MSB: 0
    Air Coding Format: Transparent Data
    Retransmission effort: Optimize for link quality (0x02)
    Packet type: 0x03c8
    EV3 may be used
    2-EV3 may not be used
    3-EV3 may not be used
    2-EV5 may not be used
    3-EV5 may not be used
    > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) ncmd 1
    Status: Success (0x00)
    > HCI Event: Max Slots Change (0x1b) plen 3
    Handle: 256
    Max slots: 5
    > HCI Event: Max Slots Change (0x1b) plen 3
    Handle: 256
    Max slots: 1
    > HCI Event: Synchronous Connect Complete (0x2c) plen 17
    Status: Success (0x00)
    Handle: 257
    Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
    Link type: eSCO (0x02)
    Transmission interval: 0x06
    Retransmission window: 0x04
    RX packet length: 30
    TX packet length: 30
    Air mode: Transparent (0x03)

    Signed-off-by: Hsin-Yu Chao
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Hsin-Yu Chao
     

13 Apr, 2020

1 commit

  • commit 71811cac8532b2387b3414f7cd8fe9e497482864 upstream.

    Needn't call 'rfcomm_dlc_put' here, because 'rfcomm_dlc_exists' didn't
    increase dlc->refcnt.

    Reported-by: syzbot+4496e82090657320efc6@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang
    Suggested-by: Hillf Danton
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Qiujun Huang
     

06 Feb, 2020

1 commit

  • commit 11eb85ec42dc8c7a7ec519b90ccf2eeae9409de8 upstream.

    Syzbot managed to trigger a use after free "KASAN: use-after-free Write
    in hci_sock_bind". I have reviewed the code manually and one possibly
    cause I have found is that we are not holding lock_sock(sk) when we do
    the hci_dev_put(hdev) in hci_sock_release(). My theory is that the bind
    and the release are racing against each other which results in this use
    after free.

    Reported-by: syzbot+eba992608adf3d796bcc@syzkaller.appspotmail.com
    Signed-off-by: Dan Carpenter
    Signed-off-by: Johan Hedberg
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     

01 Feb, 2020

1 commit

  • [ Upstream commit 7fdf6c6a0d0e032aac2aa4537a23af1e04a397ce ]

    When utilizing BDADDR_PROPERTY and INVALID_BDADDR quirks together it
    results in an unconfigured controller even if the bootloader provides
    a valid address. Fix this by allowing a bootloader provided address
    to mark the controller as configured.

    Signed-off-by: Marcel Holtmann
    Tested-by: Andre Heider
    Signed-off-by: Johan Hedberg
    Signed-off-by: Sasha Levin

    Marcel Holtmann
     

09 Jan, 2020

2 commits

  • commit d088337c38a5cd8f0230fbf2d514ff7672f9d0d3 upstream.

    In the implementation of hci_connect_le_scan() when conn is added via
    hci_conn_add(), if hci_explicit_conn_params_set() fails the allocated
    memory for conn is leaked. Use hci_conn_del() to release it.

    Fixes: f75113a26008 ("Bluetooth: add hci_connect_le_scan")
    Signed-off-by: Navid Emamdoost
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Navid Emamdoost
     
  • commit df66499a1fab340c167250a5743931dc50d5f0fa upstream.

    We used to take a lock in amp_physical_cfm() but then we moved it to
    the caller function. Unfortunately the unlock on this error path was
    overlooked so it leads to a double unlock.

    Fixes: a514b17fab51 ("Bluetooth: Refactor locking in amp_physical_cfm")
    Signed-off-by: Dan Carpenter
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Greg Kroah-Hartman

    Dan Carpenter
     

31 Dec, 2019

4 commits

  • [ Upstream commit 6012b9346d8959194c239fd60a62dfec98d43048 ]

    Instances may have flags set as part of its data in which case the code
    should not attempt to add it again otherwise it can cause duplication:

    < HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 35
    Handle: 0x00
    Operation: Complete extended advertising data (0x03)
    Fragment preference: Minimize fragmentation (0x01)
    Data length: 0x06
    Flags: 0x04
    BR/EDR Not Supported
    Flags: 0x06
    LE General Discoverable Mode
    BR/EDR Not Supported

    Signed-off-by: Luiz Augusto von Dentz
    Signed-off-by: Johan Hedberg
    Signed-off-by: Sasha Levin

    Luiz Augusto von Dentz
     
  • [ Upstream commit eb8c101e28496888a0dcfe16ab86a1bee369e820 ]

    During the setup() stage, HCI device drivers expect the chip to
    acknowledge its setup() completion via vendor specific frames.

    If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
    the vendor specific frames are never tranmitted to the driver, as
    they are filtered in hci_rx_work().

    Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive
    frames if the HCI device is is HCI_INIT state.

    [1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html

    Fixes: 23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user operation")
    Signed-off-by: Mattijs Korpershoek
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Mattijs Korpershoek
     
  • [ Upstream commit 4c371bb95cf06ded80df0e6139fdd77cee1d9a94 ]

    It appears that some Broadcom controllers (eg BCM20702A0) reject LE Set
    Advertising Parameters command if advertising intervals provided are not
    within range for undirected and low duty directed advertising.

    Workaround this bug by populating min and max intervals with 'valid'
    values.

    < HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
    Min advertising interval: 0.000 msec (0x0000)
    Max advertising interval: 0.000 msec (0x0000)
    Type: Connectable directed - ADV_DIRECT_IND (high duty cycle) (0x01)
    Own address type: Public (0x00)
    Direct address type: Random (0x01)
    Direct address: E2:F0:7B:9F:DC:F4 (Static)
    Channel map: 37, 38, 39 (0x07)
    Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
    > HCI Event: Command Complete (0x0e) plen 4
    LE Set Advertising Parameters (0x08|0x0006) ncmd 1
    Status: Invalid HCI Command Parameters (0x12)

    Signed-off-by: Szymon Janc
    Tested-by: Sören Beye
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Szymon Janc
     
  • [ Upstream commit 727ea61a5028f8ac96f75ab34cb1b56e63fd9227 ]

    It looks like in hci_init4_req() the request is being
    initialised from cpu-endian data but the packet is specified
    to be little-endian. This causes an warning from sparse due
    to __le16 to u16 conversion.

    Fix this by using cpu_to_le16() on the two fields in the packet.

    net/bluetooth/hci_core.c:845:27: warning: incorrect type in assignment (different base types)
    net/bluetooth/hci_core.c:845:27: expected restricted __le16 [usertype] tx_len
    net/bluetooth/hci_core.c:845:27: got unsigned short [usertype] le_max_tx_len
    net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment (different base types)
    net/bluetooth/hci_core.c:846:28: expected restricted __le16 [usertype] tx_time
    net/bluetooth/hci_core.c:846:28: got unsigned short [usertype] le_max_tx_time

    Signed-off-by: Ben Dooks
    Signed-off-by: Marcel Holtmann
    Signed-off-by: Sasha Levin

    Ben Dooks (Codethink)
     

29 Oct, 2019

1 commit


25 Oct, 2019

1 commit

  • Some interface types could be nested.
    (VLAN, BONDING, TEAM, MACSEC, MACVLAN, IPVLAN, VIRT_WIFI, VXLAN, etc..)
    These interface types should set lockdep class because, without lockdep
    class key, lockdep always warn about unexisting circular locking.

    In the current code, these interfaces have their own lockdep class keys and
    these manage itself. So that there are so many duplicate code around the
    /driver/net and /net/.
    This patch adds new generic lockdep keys and some helper functions for it.

    This patch does below changes.
    a) Add lockdep class keys in struct net_device
    - qdisc_running, xmit, addr_list, qdisc_busylock
    - these keys are used as dynamic lockdep key.
    b) When net_device is being allocated, lockdep keys are registered.
    - alloc_netdev_mqs()
    c) When net_device is being free'd llockdep keys are unregistered.
    - free_netdev()
    d) Add generic lockdep key helper function
    - netdev_register_lockdep_key()
    - netdev_unregister_lockdep_key()
    - netdev_update_lockdep_key()
    e) Remove unnecessary generic lockdep macro and functions
    f) Remove unnecessary lockdep code of each interfaces.

    After this patch, each interface modules don't need to maintain
    their lockdep keys.

    Signed-off-by: Taehee Yoo
    Signed-off-by: David S. Miller

    Taehee Yoo
     

19 Sep, 2019

2 commits

  • Pull networking updates from David Miller:

    1) Support IPV6 RA Captive Portal Identifier, from Maciej Żenczykowski.

    2) Use bio_vec in the networking instead of custom skb_frag_t, from
    Matthew Wilcox.

    3) Make use of xmit_more in r8169 driver, from Heiner Kallweit.

    4) Add devmap_hash to xdp, from Toke Høiland-Jørgensen.

    5) Support all variants of 5750X bnxt_en chips, from Michael Chan.

    6) More RTNL avoidance work in the core and mlx5 driver, from Vlad
    Buslov.

    7) Add TCP syn cookies bpf helper, from Petar Penkov.

    8) Add 'nettest' to selftests and use it, from David Ahern.

    9) Add extack support to drop_monitor, add packet alert mode and
    support for HW drops, from Ido Schimmel.

    10) Add VLAN offload to stmmac, from Jose Abreu.

    11) Lots of devm_platform_ioremap_resource() conversions, from
    YueHaibing.

    12) Add IONIC driver, from Shannon Nelson.

    13) Several kTLS cleanups, from Jakub Kicinski.

    * git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1930 commits)
    mlxsw: spectrum_buffers: Add the ability to query the CPU port's shared buffer
    mlxsw: spectrum: Register CPU port with devlink
    mlxsw: spectrum_buffers: Prevent changing CPU port's configuration
    net: ena: fix incorrect update of intr_delay_resolution
    net: ena: fix retrieval of nonadaptive interrupt moderation intervals
    net: ena: fix update of interrupt moderation register
    net: ena: remove all old adaptive rx interrupt moderation code from ena_com
    net: ena: remove ena_restore_ethtool_params() and relevant fields
    net: ena: remove old adaptive interrupt moderation code from ena_netdev
    net: ena: remove code duplication in ena_com_update_nonadaptive_moderation_interval _*()
    net: ena: enable the interrupt_moderation in driver_supported_features
    net: ena: reimplement set/get_coalesce()
    net: ena: switch to dim algorithm for rx adaptive interrupt moderation
    net: ena: add intr_moder_rx_interval to struct ena_com_dev and use it
    net: phy: adin: implement Energy Detect Powerdown mode via phy-tunable
    ethtool: implement Energy Detect Powerdown support via phy-tunable
    xen-netfront: do not assume sk_buff_head list is empty in error handling
    s390/ctcm: Delete unnecessary checks before the macro call “dev_kfree_skb”
    net: ena: don't wake up tx queue when down
    drop_monitor: Better sanitize notified packets
    ...

    Linus Torvalds
     
  • Pull crypto updates from Herbert Xu:
    "API:
    - Add the ability to abort a skcipher walk.

    Algorithms:
    - Fix XTS to actually do the stealing.
    - Add library helpers for AES and DES for single-block users.
    - Add library helpers for SHA256.
    - Add new DES key verification helper.
    - Add surrounding bits for ESSIV generator.
    - Add accelerations for aegis128.
    - Add test vectors for lzo-rle.

    Drivers:
    - Add i.MX8MQ support to caam.
    - Add gcm/ccm/cfb/ofb aes support in inside-secure.
    - Add ofb/cfb aes support in media-tek.
    - Add HiSilicon ZIP accelerator support.

    Others:
    - Fix potential race condition in padata.
    - Use unbound workqueues in padata"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (311 commits)
    crypto: caam - Cast to long first before pointer conversion
    crypto: ccree - enable CTS support in AES-XTS
    crypto: inside-secure - Probe transform record cache RAM sizes
    crypto: inside-secure - Base RD fetchcount on actual RD FIFO size
    crypto: inside-secure - Base CD fetchcount on actual CD FIFO size
    crypto: inside-secure - Enable extended algorithms on newer HW
    crypto: inside-secure: Corrected configuration of EIP96_TOKEN_CTRL
    crypto: inside-secure - Add EIP97/EIP197 and endianness detection
    padata: remove cpu_index from the parallel_queue
    padata: unbind parallel jobs from specific CPUs
    padata: use separate workqueues for parallel and serial work
    padata, pcrypt: take CPU hotplug lock internally in padata_alloc_possible
    crypto: pcrypt - remove padata cpumask notifier
    padata: make padata_do_parallel find alternate callback CPU
    workqueue: require CPU hotplug read exclusion for apply_workqueue_attrs
    workqueue: unconfine alloc/apply/free_workqueue_attrs()
    padata: allocate workqueue internally
    arm64: dts: imx8mq: Add CAAM node
    random: Use wait_event_freezable() in add_hwgenerator_randomness()
    crypto: ux500 - Fix COMPILE_TEST warnings
    ...

    Linus Torvalds
     

15 Sep, 2019

1 commit


06 Sep, 2019

1 commit

  • hidp_send_message was changed to return non-zero values on success,
    which some other bits did not expect. This caused spurious errors to be
    propagated through the stack, breaking some drivers, such as hid-sony
    for the Dualshock 4 in Bluetooth mode.

    As pointed out by Dan Carpenter, hid-microsoft directly relied on that
    assumption as well.

    Fixes: 48d9cc9d85dd ("Bluetooth: hidp: Let hidp_send_message return number of queued bytes")

    Signed-off-by: Dan Elkouby
    Reviewed-by: Dan Carpenter
    Reviewed-by: Jiri Kosina
    Signed-off-by: Marcel Holtmann

    Dan Elkouby
     

05 Sep, 2019

4 commits

  • One of the more common cases of allocation size calculations is finding
    the size of a structure that has a zero-sized array at the end, along
    with memory for some number of elements for that array. For example:

    struct mgmt_rp_get_connections {
    ...
    struct mgmt_addr_info addr[0];
    } __packed;

    Make use of the struct_size() helper instead of an open-coded version
    in order to avoid any potential type mistakes.

    So, replace the following form:

    sizeof(*rp) + (i * sizeof(struct mgmt_addr_info));

    with:

    struct_size(rp, addr, i)

    Also, notice that, in this case, variable rp_len is not necessary,
    hence it is removed.

    This code was detected with the help of Coccinelle.

    Signed-off-by: Gustavo A. R. Silva
    Signed-off-by: Marcel Holtmann

    Gustavo A. R. Silva
     
  • Static variable header_ops, of type header_ops, is used only once, when
    it is assigned to field header_ops of a variable having type net_device.
    This corresponding field is declared as const in the definition of
    net_device. Hence make header_ops constant as well to protect it from
    unnecessary modification.
    Issue found with Coccinelle.

    Signed-off-by: Nishka Dasgupta
    Signed-off-by: Marcel Holtmann

    Nishka Dasgupta
     
  • Changes made to add support for fast advertising interval
    as per core 4.1 specification, section 9.3.11.2.

    A peripheral device entering any of the following GAP modes and
    sending either non-connectable advertising events or scannable
    undirected advertising events should use adv_fast_interval2
    (100ms - 150ms) for adv_fast_period(30s).

    - Non-Discoverable Mode
    - Non-Connectable Mode
    - Limited Discoverable Mode
    - General Discoverable Mode

    Signed-off-by: Spoorthi Ravishankar Koppad
    Signed-off-by: Marcel Holtmann

    Spoorthi Ravishankar Koppad
     
  • This reverts commit c49a8682fc5d298d44e8d911f4fa14690ea9485e.

    There are devices which require low connection intervals for usable operation
    including keyboards and mice. Forcing a static connection interval for
    these types of devices has an impact in latency and causes a regression.

    Signed-off-by: Marcel Holtmann
    Signed-off-by: Johan Hedberg

    Marcel Holtmann
     

17 Aug, 2019

1 commit


13 Aug, 2019

1 commit

  • Let hidp_send_message return the number of successfully queued bytes
    instead of an unconditional 0.

    With the return value fixed to 0, other drivers relying on hidp, such as
    hidraw, can not return meaningful values from their respective
    implementations of write(). In particular, with the current behavior, a
    hidraw device's write() will have different return values depending on
    whether the device is connected via USB or Bluetooth, which makes it
    harder to abstract away the transport layer.

    Signed-off-by: Fabian Henneke
    Signed-off-by: Marcel Holtmann

    Fabian Henneke