1. 10 Apr, 2023 8 commits
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix possible UAF · 5dc7d23e
      Luiz Augusto von Dentz authored
      This fixes the following trace:
      
      ==================================================================
      BUG: KASAN: slab-use-after-free in hci_conn_del+0xba/0x3a0
      Write of size 8 at addr ffff88800208e9c8 by task iso-tester/31
      
      CPU: 0 PID: 31 Comm: iso-tester Not tainted 6.3.0-rc2-g991aa4a69a47
       #4716
      Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc36
      04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x1d/0x70
       print_report+0xce/0x610
       ? __virt_addr_valid+0xd4/0x150
       ? hci_conn_del+0xba/0x3a0
       kasan_report+0xdd/0x110
       ? hci_conn_del+0xba/0x3a0
       hci_conn_del+0xba/0x3a0
       hci_conn_hash_flush+0xf2/0x120
       hci_dev_close_sync+0x388/0x920
       hci_unregister_dev+0x122/0x260
       vhci_release+0x4f/0x90
       __fput+0x102/0x430
       task_work_run+0xf1/0x160
       ? __pfx_task_work_run+0x10/0x10
       ? mark_held_locks+0x24/0x90
       exit_to_user_mode_prepare+0x170/0x180
       syscall_exit_to_user_mode+0x19/0x50
       do_syscall_64+0x4e/0x90
       entry_SYSCALL_64_after_hwframe+0x70/0xda
      
      Fixes: 0f00cd32 ("Bluetooth: Free potentially unfreed SCO connection")
      Link: https://syzkaller.appspot.com/bug?extid=8bb72f86fc823817bc5d
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      5dc7d23e
    • Luiz Augusto von Dentz's avatar
      Bluetooth: SCO: Fix possible circular locking dependency sco_sock_getsockopt · 975abc0c
      Luiz Augusto von Dentz authored
      This attempts to fix the following trace:
      
      ======================================================
      WARNING: possible circular locking dependency detected
      6.3.0-rc2-g68fcb3a7bf97 #4706 Not tainted
      ------------------------------------------------------
      sco-tester/31 is trying to acquire lock:
      ffff8880025b8070 (&hdev->lock){+.+.}-{3:3}, at:
      sco_sock_getsockopt+0x1fc/0xa90
      
      but task is already holding lock:
      ffff888001eeb130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at:
      sco_sock_getsockopt+0x104/0xa90
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
             lock_sock_nested+0x32/0x80
             sco_connect_cfm+0x118/0x4a0
             hci_sync_conn_complete_evt+0x1e6/0x3d0
             hci_event_packet+0x55c/0x7c0
             hci_rx_work+0x34c/0xa00
             process_one_work+0x575/0x910
             worker_thread+0x89/0x6f0
             kthread+0x14e/0x180
             ret_from_fork+0x2b/0x50
      
      -> #1 (hci_cb_list_lock){+.+.}-{3:3}:
             __mutex_lock+0x13b/0xcc0
             hci_sync_conn_complete_evt+0x1ad/0x3d0
             hci_event_packet+0x55c/0x7c0
             hci_rx_work+0x34c/0xa00
             process_one_work+0x575/0x910
             worker_thread+0x89/0x6f0
             kthread+0x14e/0x180
             ret_from_fork+0x2b/0x50
      
      -> #0 (&hdev->lock){+.+.}-{3:3}:
             __lock_acquire+0x18cc/0x3740
             lock_acquire+0x151/0x3a0
             __mutex_lock+0x13b/0xcc0
             sco_sock_getsockopt+0x1fc/0xa90
             __sys_getsockopt+0xe9/0x190
             __x64_sys_getsockopt+0x5b/0x70
             do_syscall_64+0x42/0x90
             entry_SYSCALL_64_after_hwframe+0x70/0xda
      
      other info that might help us debug this:
      
      Chain exists of:
        &hdev->lock --> hci_cb_list_lock --> sk_lock-AF_BLUETOOTH-BTPROTO_SCO
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
                                     lock(hci_cb_list_lock);
                                     lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
        lock(&hdev->lock);
      
       *** DEADLOCK ***
      
      1 lock held by sco-tester/31:
       #0: ffff888001eeb130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0},
       at: sco_sock_getsockopt+0x104/0xa90
      
      Fixes: 248733e8 ("Bluetooth: Allow querying of supported offload codecs over SCO socket")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      975abc0c
    • Luiz Augusto von Dentz's avatar
      Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm · 9a8ec9e8
      Luiz Augusto von Dentz authored
      This attempts to fix the following trace:
      
      ======================================================
      WARNING: possible circular locking dependency detected
      6.3.0-rc2-g0b93eeba4454 #4703 Not tainted
      ------------------------------------------------------
      kworker/u3:0/46 is trying to acquire lock:
      ffff888001fd9130 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at:
      sco_connect_cfm+0x118/0x4a0
      
      but task is already holding lock:
      ffffffff831e3340 (hci_cb_list_lock){+.+.}-{3:3}, at:
      hci_sync_conn_complete_evt+0x1ad/0x3d0
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (hci_cb_list_lock){+.+.}-{3:3}:
             __mutex_lock+0x13b/0xcc0
             hci_sync_conn_complete_evt+0x1ad/0x3d0
             hci_event_packet+0x55c/0x7c0
             hci_rx_work+0x34c/0xa00
             process_one_work+0x575/0x910
             worker_thread+0x89/0x6f0
             kthread+0x14e/0x180
             ret_from_fork+0x2b/0x50
      
      -> #1 (&hdev->lock){+.+.}-{3:3}:
             __mutex_lock+0x13b/0xcc0
             sco_sock_connect+0xfc/0x630
             __sys_connect+0x197/0x1b0
             __x64_sys_connect+0x37/0x50
             do_syscall_64+0x42/0x90
             entry_SYSCALL_64_after_hwframe+0x70/0xda
      
      -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}:
             __lock_acquire+0x18cc/0x3740
             lock_acquire+0x151/0x3a0
             lock_sock_nested+0x32/0x80
             sco_connect_cfm+0x118/0x4a0
             hci_sync_conn_complete_evt+0x1e6/0x3d0
             hci_event_packet+0x55c/0x7c0
             hci_rx_work+0x34c/0xa00
             process_one_work+0x575/0x910
             worker_thread+0x89/0x6f0
             kthread+0x14e/0x180
             ret_from_fork+0x2b/0x50
      
      other info that might help us debug this:
      
      Chain exists of:
        sk_lock-AF_BLUETOOTH-BTPROTO_SCO --> &hdev->lock --> hci_cb_list_lock
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(hci_cb_list_lock);
                                     lock(&hdev->lock);
                                     lock(hci_cb_list_lock);
        lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO);
      
       *** DEADLOCK ***
      
      4 locks held by kworker/u3:0/46:
       #0: ffff8880028d1130 ((wq_completion)hci0#2){+.+.}-{0:0}, at:
       process_one_work+0x4c0/0x910
       #1: ffff8880013dfde0 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0},
       at: process_one_work+0x4c0/0x910
       #2: ffff8880025d8070 (&hdev->lock){+.+.}-{3:3}, at:
       hci_sync_conn_complete_evt+0xa6/0x3d0
       #3: ffffffffb79e3340 (hci_cb_list_lock){+.+.}-{3:3}, at:
       hci_sync_conn_complete_evt+0x1ad/0x3d0
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      9a8ec9e8
    • Sasha Finkelstein's avatar
      bluetooth: btbcm: Fix logic error in forming the board name. · b76abe46
      Sasha Finkelstein authored
      This patch fixes an incorrect loop exit condition in code that replaces
      '/' symbols in the board name. There might also be a memory corruption
      issue here, but it is unlikely to be a real problem.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarSasha Finkelstein <fnkl.kernel@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b76abe46
    • Zheng Wang's avatar
      Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition · 73f7b171
      Zheng Wang authored
      In btsdio_probe, the data->work is bound with btsdio_work. It will be
      started in btsdio_send_frame.
      
      If the btsdio_remove runs with a unfinished work, there may be a race
      condition that hdev is freed but used in btsdio_work. Fix it by
      canceling the work before do cleanup in btsdio_remove.
      Signed-off-by: default avatarZheng Wang <zyytlz.wz@163.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      73f7b171
    • Min Li's avatar
      Bluetooth: Fix race condition in hidp_session_thread · c95930ab
      Min Li authored
      There is a potential race condition in hidp_session_thread that may
      lead to use-after-free. For instance, the timer is active while
      hidp_del_timer is called in hidp_session_thread(). After hidp_session_put,
      then 'session' will be freed, causing kernel panic when hidp_idle_timeout
      is running.
      
      The solution is to use del_timer_sync instead of del_timer.
      
      Here is the call trace:
      
      ? hidp_session_probe+0x780/0x780
      call_timer_fn+0x2d/0x1e0
      __run_timers.part.0+0x569/0x940
      hidp_session_probe+0x780/0x780
      call_timer_fn+0x1e0/0x1e0
      ktime_get+0x5c/0xf0
      lapic_next_deadline+0x2c/0x40
      clockevents_program_event+0x205/0x320
      run_timer_softirq+0xa9/0x1b0
      __do_softirq+0x1b9/0x641
      __irq_exit_rcu+0xdc/0x190
      irq_exit_rcu+0xe/0x20
      sysvec_apic_timer_interrupt+0xa1/0xc0
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMin Li <lm0963hack@gmail.com>
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      c95930ab
    • Luiz Augusto von Dentz's avatar
      Bluetooth: Fix printing errors if LE Connection times out · b62e7220
      Luiz Augusto von Dentz authored
      This fixes errors like bellow when LE Connection times out since that
      is actually not a controller error:
      
       Bluetooth: hci0: Opcode 0x200d failed: -110
       Bluetooth: hci0: request failed to create LE connection: err -110
      
      Instead the code shall properly detect if -ETIMEDOUT is returned and
      send HCI_OP_LE_CREATE_CONN_CANCEL to give up on the connection.
      
      Link: https://github.com/bluez/bluez/issues/340
      Fixes: 8e8b92ee ("Bluetooth: hci_sync: Add hci_le_create_conn_sync")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      b62e7220
    • Luiz Augusto von Dentz's avatar
      Bluetooth: hci_conn: Fix not cleaning up on LE Connection failure · 19cf60bf
      Luiz Augusto von Dentz authored
      hci_connect_le_scan_cleanup shall always be invoked to cleanup the
      states and re-enable passive scanning if necessary, otherwise it may
      cause the pending action to stay active causing multiple attempts to
      connect.
      
      Fixes: 9b3628d7 ("Bluetooth: hci_sync: Cleanup hci_conn if it cannot be aborted")
      Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
      19cf60bf
  2. 07 Apr, 2023 6 commits
    • David S. Miller's avatar
      Merge branch 'bonding-ns-validation-fixes' · b9881d9a
      David S. Miller authored
      Hangbin Liu says:
      
      ====================
      bonding: fix ns validation on backup slaves
      
      The first patch fixed a ns validation issue on backup slaves. The second
      patch re-format the bond option test and add a test lib file. The third
      patch add the arp validate regression test for the kernel patch.
      
      Here is the new bonding option test without the kernel fix:
      
      ]# ./bond_options.sh
      TEST: prio (active-backup miimon primary_reselect 0)           [ OK ]
      TEST: prio (active-backup miimon primary_reselect 1)           [ OK ]
      TEST: prio (active-backup miimon primary_reselect 2)           [ OK ]
      TEST: prio (active-backup arp_ip_target primary_reselect 0)    [ OK ]
      TEST: prio (active-backup arp_ip_target primary_reselect 1)    [ OK ]
      TEST: prio (active-backup arp_ip_target primary_reselect 2)    [ OK ]
      TEST: prio (active-backup ns_ip6_target primary_reselect 0)    [ OK ]
      TEST: prio (active-backup ns_ip6_target primary_reselect 1)    [ OK ]
      TEST: prio (active-backup ns_ip6_target primary_reselect 2)    [ OK ]
      TEST: prio (balance-tlb miimon primary_reselect 0)             [ OK ]
      TEST: prio (balance-tlb miimon primary_reselect 1)             [ OK ]
      TEST: prio (balance-tlb miimon primary_reselect 2)             [ OK ]
      TEST: prio (balance-tlb arp_ip_target primary_reselect 0)      [ OK ]
      TEST: prio (balance-tlb arp_ip_target primary_reselect 1)      [ OK ]
      TEST: prio (balance-tlb arp_ip_target primary_reselect 2)      [ OK ]
      TEST: prio (balance-tlb ns_ip6_target primary_reselect 0)      [ OK ]
      TEST: prio (balance-tlb ns_ip6_target primary_reselect 1)      [ OK ]
      TEST: prio (balance-tlb ns_ip6_target primary_reselect 2)      [ OK ]
      TEST: prio (balance-alb miimon primary_reselect 0)             [ OK ]
      TEST: prio (balance-alb miimon primary_reselect 1)             [ OK ]
      TEST: prio (balance-alb miimon primary_reselect 2)             [ OK ]
      TEST: prio (balance-alb arp_ip_target primary_reselect 0)      [ OK ]
      TEST: prio (balance-alb arp_ip_target primary_reselect 1)      [ OK ]
      TEST: prio (balance-alb arp_ip_target primary_reselect 2)      [ OK ]
      TEST: prio (balance-alb ns_ip6_target primary_reselect 0)      [ OK ]
      TEST: prio (balance-alb ns_ip6_target primary_reselect 1)      [ OK ]
      TEST: prio (balance-alb ns_ip6_target primary_reselect 2)      [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 0)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 1)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 2)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 3)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 4)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 5)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 6)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 0)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 1)  [ OK ]
      TEST: arp_validate (interface eth1 mii_status DOWN)                 [FAIL]
      TEST: arp_validate (interface eth2 mii_status DOWN)                 [FAIL]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 2)  [FAIL]
      TEST: arp_validate (interface eth1 mii_status DOWN)                 [FAIL]
      TEST: arp_validate (interface eth2 mii_status DOWN)                 [FAIL]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 3)  [FAIL]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 4)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 5)  [ OK ]
      TEST: arp_validate (interface eth1 mii_status DOWN)                 [FAIL]
      TEST: arp_validate (interface eth2 mii_status DOWN)                 [FAIL]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 6)  [FAIL]
      
      Here is the test result after the kernel fix:
      TEST: arp_validate (active-backup arp_ip_target arp_validate 0)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 1)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 2)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 3)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 4)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 5)  [ OK ]
      TEST: arp_validate (active-backup arp_ip_target arp_validate 6)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 0)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 1)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 2)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 3)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 4)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 5)  [ OK ]
      TEST: arp_validate (active-backup ns_ip6_target arp_validate 6)  [ OK ]
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9881d9a
    • Hangbin Liu's avatar
      selftests: bonding: add arp validate test · 2e825f8a
      Hangbin Liu authored
      This patch add bonding arp validate tests with mode active backup,
      monitor arp_ip_target and ns_ip6_target. It also checks mii_status
      to make sure all slaves are UP.
      Acked-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e825f8a
    • Hangbin Liu's avatar
      selftests: bonding: re-format bond option tests · 481b56e0
      Hangbin Liu authored
      To improve the testing process for bond options, A new bond topology lib
      is added to our testing setup. The current option_prio.sh file will be
      renamed to bond_options.sh so that all bonding options can be tested here.
      Specifically, for priority testing, we will run all tests using modes
      1, 5, and 6. These changes will help us streamline the testing process
      and ensure that our bond options are rigorously evaluated.
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Acked-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      481b56e0
    • Hangbin Liu's avatar
      bonding: fix ns validation on backup slaves · 4598380f
      Hangbin Liu authored
      When arp_validate is set to 2, 3, or 6, validation is performed for
      backup slaves as well. As stated in the bond documentation, validation
      involves checking the broadcast ARP request sent out via the active
      slave. This helps determine which slaves are more likely to function in
      the event of an active slave failure.
      
      However, when the target is an IPv6 address, the NS message sent from
      the active interface is not checked on backup slaves. Additionally,
      based on the bond_arp_rcv() rule b, we must reverse the saddr and daddr
      when checking the NS message.
      
      Note that when checking the NS message, the destination address is a
      multicast address. Therefore, we must convert the target address to
      solicited multicast in the bond_get_targets_ip6() function.
      
      Prior to the fix, the backup slaves had a mii status of "down", but
      after the fix, all of the slaves' mii status was updated to "UP".
      
      Fixes: 4e24be01 ("bonding: add new parameter ns_targets")
      Reviewed-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4598380f
    • YueHaibing's avatar
      tcp: restrict net.ipv4.tcp_app_win · dc5110c2
      YueHaibing authored
      UBSAN: shift-out-of-bounds in net/ipv4/tcp_input.c:555:23
      shift exponent 255 is too large for 32-bit type 'int'
      CPU: 1 PID: 7907 Comm: ssh Not tainted 6.3.0-rc4-00161-g62bad54b-dirty #206
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
      Call Trace:
       <TASK>
       dump_stack_lvl+0x136/0x150
       __ubsan_handle_shift_out_of_bounds+0x21f/0x5a0
       tcp_init_transfer.cold+0x3a/0xb9
       tcp_finish_connect+0x1d0/0x620
       tcp_rcv_state_process+0xd78/0x4d60
       tcp_v4_do_rcv+0x33d/0x9d0
       __release_sock+0x133/0x3b0
       release_sock+0x58/0x1b0
      
      'maxwin' is int, shifting int for 32 or more bits is undefined behaviour.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dc5110c2
    • Harshit Mogalapalli's avatar
      niu: Fix missing unwind goto in niu_alloc_channels() · 8ce07be7
      Harshit Mogalapalli authored
      Smatch reports: drivers/net/ethernet/sun/niu.c:4525
      	niu_alloc_channels() warn: missing unwind goto?
      
      If niu_rbr_fill() fails, then we are directly returning 'err' without
      freeing the channels.
      
      Fix this by changing direct return to a goto 'out_err'.
      
      Fixes: a3138df9 ("[NIU]: Add Sun Neptune ethernet driver.")
      Signed-off-by: default avatarHarshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ce07be7
  3. 06 Apr, 2023 15 commits
  4. 05 Apr, 2023 11 commits