Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix a race on command flush flow<br /> <br /> Fix a refcount use after free warning due to a race on command entry.<br /> Such race occurs when one of the commands releases its last refcount and<br /> frees its index and entry while another process running command flush<br /> flow takes refcount to this command entry. The process which handles<br /> commands flush may see this command as needed to be flushed if the other<br /> process released its refcount but didn&amp;#39;t release the index yet. Fix it<br /> by adding the needed spin lock.<br /> <br /> It fixes the following warning trace:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0<br /> ...<br /> RIP: 0010:refcount_warn_saturate+0x80/0xe0<br /> ...<br /> Call Trace:<br /> <br /> mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core]<br /> mlx5_cmd_flush+0x3a/0xf0 [mlx5_core]<br /> enter_error_state+0x44/0x80 [mlx5_core]<br /> mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core]<br /> process_one_work+0x1be/0x390<br /> worker_thread+0x4d/0x3d0<br /> ? rescuer_thread+0x350/0x350<br /> kthread+0x141/0x160<br /> ? set_kthread_struct+0x40/0x40<br /> ret_from_fork+0x1f/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr<br /> <br /> This node pointer is returned by of_find_compatible_node() with<br /> refcount incremented. Calling of_node_put() to aovid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethernet: Fix error handling in xemaclite_of_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with refcount<br /> incremented in this function. Calling of_node_put() to avoid the<br /> refcount leak. As the remove function do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> swiotlb: fix info leak with DMA_FROM_DEVICE<br /> <br /> The problem I&amp;#39;m addressing was discovered by the LTP test covering<br /> cve-2018-1000204.<br /> <br /> A short description of what happens follows:<br /> 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO<br /> interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV<br /> and a corresponding dxferp. The peculiar thing about this is that TUR<br /> is not reading from the device.<br /> 2) In sg_start_req() the invocation of blk_rq_map_user() effectively<br /> bounces the user-space buffer. As if the device was to transfer into<br /> it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in<br /> sg_build_indirect()") we make sure this first bounce buffer is<br /> allocated with GFP_ZERO.<br /> 3) For the rest of the story we keep ignoring that we have a TUR, so the<br /> device won&amp;#39;t touch the buffer we prepare as if the we had a<br /> DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device<br /> and the buffer allocated by SG is mapped by the function<br /> virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here<br /> scatter-gather and not scsi generics). This mapping involves bouncing<br /> via the swiotlb (we need swiotlb to do virtio in protected guest like<br /> s390 Secure Execution, or AMD SEV).<br /> 4) When the SCSI TUR is done, we first copy back the content of the second<br /> (that is swiotlb) bounce buffer (which most likely contains some<br /> previous IO data), to the first bounce buffer, which contains all<br /> zeros. Then we copy back the content of the first bounce buffer to<br /> the user-space buffer.<br /> 5) The test case detects that the buffer, which it zero-initialized,<br /> ain&amp;#39;t all zeros and fails.<br /> <br /> One can argue that this is an swiotlb problem, because without swiotlb<br /> we leak all zeros, and the swiotlb should be transparent in a sense that<br /> it does not affect the outcome (if all other participants are well<br /> behaved).<br /> <br /> Copying the content of the original buffer into the swiotlb buffer is<br /> the only way I can think of to make swiotlb transparent in such<br /> scenarios. So let&amp;#39;s do just that if in doubt, but allow the driver<br /> to tell us that the whole mapped buffer is going to be overwritten,<br /> in which case we can preserve the old behavior and avoid the performance<br /> impact of the extra bounce.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Page fault in reply q processing<br /> <br /> A page fault was encountered in mpt3sas on a LUN reset error path:<br /> <br /> [ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0)<br /> [ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2)<br /> [ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2)<br /> [ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00<br /> [ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0)<br /> [ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0)<br /> [ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002)<br /> [ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d<br /> [ 149.885617] #PF: supervisor read access in kernel mode<br /> [ 149.894346] #PF: error_code(0x0000) - not-present page<br /> [ 149.903123] PGD 0 P4D 0<br /> [ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1<br /> [ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021<br /> [ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas]<br /> [ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee<br /> [ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246<br /> [ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071<br /> [ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8<br /> [ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff<br /> [ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000<br /> [ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80<br /> [ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000<br /> [ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0<br /> [ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 150.108323] PKRU: 55555554<br /> [ 150.114690] Call Trace:<br /> [ 150.120497] ? printk+0x48/0x4a<br /> [ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas]<br /> [ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas]<br /> [ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas]<br /> [ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod]<br /> [ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod]<br /> [ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]<br /> [ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60<br /> [ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod]<br /> [ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod]<br /> [ 150.203206] ? __schedule+0x1e9/0x610<br /> [ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod]<br /> [ 150.217924] kthread+0x12e/0x150<br /> [ 150.224041] ? kthread_worker_fn+0x130/0x130<br /> [ 150.231206] ret_from_fork+0x1f/0x30<br /> <br /> This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q<br /> pointer outside of the list_for_each_entry() loop. At the end of the full<br /> list traversal the pointer is invalid.<br /> <br /> Move the _base_process_reply_queue() call inside of the loop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: aiptek - properly check endpoint type<br /> <br /> Syzbot reported warning in usb_submit_urb() which is caused by wrong<br /> endpoint type. There was a check for the number of endpoints, but not<br /> for the type of endpoint.<br /> <br /> Fix it by replacing old desc.bNumEndpoints check with<br /> usb_find_common_endpoints() helper for finding endpoints<br /> <br /> Fail log:<br /> <br /> usb 5-1: BOGUS urb xfer, pipe 1 != type 3<br /> WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502<br /> Modules linked in:<br /> CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> ...<br /> Call Trace:<br /> <br /> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830<br /> input_open_device+0x1bb/0x320 drivers/input/input.c:629<br /> kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: rndis: prevent integer overflow in rndis_set_response()<br /> <br /> If "BufOffset" is very large the "BufOffset + 8" operation can have an<br /> integer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: Fix use-after-free bug by not setting udc-&gt;dev.driver<br /> <br /> The syzbot fuzzer found a use-after-free bug:<br /> <br /> BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320<br /> Read of size 8 at addr ffff88802b934098 by task udevd/3689<br /> <br /> CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold+0x83/0xdf mm/kasan/report.c:459<br /> dev_uevent+0x712/0x780 drivers/base/core.c:2320<br /> uevent_show+0x1b8/0x380 drivers/base/core.c:2391<br /> dev_attr_show+0x4b/0x90 drivers/base/core.c:2094<br /> <br /> Although the bug manifested in the driver core, the real cause was a<br /> race with the gadget core. dev_uevent() does:<br /> <br /> if (dev-&gt;driver)<br /> add_uevent_var(env, "DRIVER=%s", dev-&gt;driver-&gt;name);<br /> <br /> and between the test and the dereference of dev-&gt;driver, the gadget<br /> core sets dev-&gt;driver to NULL.<br /> <br /> The race wouldn&amp;#39;t occur if the gadget core registered its devices on<br /> a real bus, using the standard synchronization techniques of the<br /> driver core. However, it&amp;#39;s not necessary to make such a large change<br /> in order to fix this bug; all we need to do is make sure that<br /> udc-&gt;dev.driver is always NULL.<br /> <br /> In fact, there is no reason for udc-&gt;dev.driver ever to be set to<br /> anything, let alone to the value it currently gets: the address of the<br /> gadget&amp;#39;s driver. After all, a gadget driver only knows how to manage<br /> a gadget, not how to manage a UDC.<br /> <br /> This patch simply removes the statements in the gadget core that touch<br /> udc-&gt;dev.driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/packet: fix slab-out-of-bounds access in packet_recvmsg()<br /> <br /> syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH<br /> and mmap operations, tpacket_rcv() is queueing skbs with<br /> garbage in skb-&gt;cb[], triggering a too big copy [1]<br /> <br /> Presumably, users of af_packet using mmap() already gets correct<br /> metadata from the mapped buffer, we can simply make sure<br /> to clear 12 bytes that might be copied to user space later.<br /> <br /> BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]<br /> BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489<br /> Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631<br /> <br /> CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255<br /> __kasan_report mm/kasan/report.c:442 [inline]<br /> kasan_report.cold+0x83/0xdf mm/kasan/report.c:459<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189<br /> memcpy+0x39/0x60 mm/kasan/shadow.c:66<br /> memcpy include/linux/fortify-string.h:225 [inline]<br /> packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489<br /> sock_recvmsg_nosec net/socket.c:948 [inline]<br /> sock_recvmsg net/socket.c:966 [inline]<br /> sock_recvmsg net/socket.c:962 [inline]<br /> ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632<br /> ___sys_recvmsg+0x127/0x200 net/socket.c:2674<br /> __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7fdfd5954c29<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29<br /> RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005<br /> RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60<br /> R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54<br /> <br /> <br /> addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:<br /> ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246<br /> <br /> this frame has 1 object:<br /> [32, 160) &amp;#39;addr&amp;#39;<br /> <br /> Memory state around the buggy address:<br /> ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00<br /> ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00<br /> &gt;ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3<br /> ^<br /> ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1<br /> ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix hang during reboot/shutdown<br /> <br /> Recent commit 974578017fc1 ("iavf: Add waiting so the port is<br /> initialized in remove") adds a wait-loop at the beginning of<br /> iavf_remove() to ensure that port initialization is finished<br /> prior unregistering net device. This causes a regression<br /> in reboot/shutdown scenario because in this case callback<br /> iavf_shutdown() is called and this callback detaches the device,<br /> makes it down if it is running and sets its state to __IAVF_REMOVE.<br /> Later shutdown callback of associated PF driver (e.g. ice_shutdown)<br /> is called. That callback calls among other things sriov_disable()<br /> that calls indirectly iavf_remove() (see stack trace below).<br /> As the adapter state is already __IAVF_REMOVE then the mentioned<br /> loop is end-less and shutdown process hangs.<br /> <br /> The patch fixes this by checking adapter&amp;#39;s state at the beginning<br /> of iavf_remove() and skips the rest of the function if the adapter<br /> is already in remove state (shutdown is in progress).<br /> <br /> Reproducer:<br /> 1. Create VF on PF driven by ice or i40e driver<br /> 2. Ensure that the VF is bound to iavf driver<br /> 3. Reboot<br /> <br /> [52625.981294] sysrq: SysRq : Show Blocked State<br /> [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: 1 f2<br /> [52625.996732] Call Trace:<br /> [52625.999187] __schedule+0x2d1/0x830<br /> [52626.007400] schedule+0x35/0xa0<br /> [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100<br /> [52626.020046] usleep_range+0x5b/0x80<br /> [52626.023540] iavf_remove+0x63/0x5b0 [iavf]<br /> [52626.027645] pci_device_remove+0x3b/0xc0<br /> [52626.031572] device_release_driver_internal+0x103/0x1f0<br /> [52626.036805] pci_stop_bus_device+0x72/0xa0<br /> [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20<br /> [52626.045870] pci_iov_remove_virtfn+0xba/0x120<br /> [52626.050232] sriov_disable+0x2f/0xe0<br /> [52626.053813] ice_free_vfs+0x7c/0x340 [ice]<br /> [52626.057946] ice_remove+0x220/0x240 [ice]<br /> [52626.061967] ice_shutdown+0x16/0x50 [ice]<br /> [52626.065987] pci_device_shutdown+0x34/0x60<br /> [52626.070086] device_shutdown+0x165/0x1c5<br /> [52626.074011] kernel_restart+0xe/0x30<br /> [52626.077593] __do_sys_reboot+0x1d2/0x210<br /> [52626.093815] do_syscall_64+0x5b/0x1a0<br /> [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats()<br /> <br /> It is possible to do NULL pointer dereference in routine that updates<br /> Tx ring stats. Currently only stats and bytes are updated when ring<br /> pointer is valid, but later on ring is accessed to propagate gathered Tx<br /> stats onto VSI stats.<br /> <br /> Change the existing logic to move to next ring when ring is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix race condition during interface enslave<br /> <br /> Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating<br /> auxiliary device") changes a process of re-creation of aux device<br /> so ice_plug_aux_dev() is called from ice_service_task() context.<br /> This unfortunately opens a race window that can result in dead-lock<br /> when interface has left LAG and immediately enters LAG again.<br /> <br /> Reproducer:<br /> ```<br /> #!/bin/sh<br /> <br /> ip link add lag0 type bond mode 1 miimon 100<br /> ip link set lag0<br /> <br /> for n in {1..10}; do<br /> echo Cycle: $n<br /> ip link set ens7f0 master lag0<br /> sleep 1<br /> ip link set ens7f0 nomaster<br /> done<br /> ```<br /> <br /> This results in:<br /> [20976.208697] Workqueue: ice ice_service_task [ice]<br /> [20976.213422] Call Trace:<br /> [20976.215871] __schedule+0x2d1/0x830<br /> [20976.219364] schedule+0x35/0xa0<br /> [20976.222510] schedule_preempt_disabled+0xa/0x10<br /> [20976.227043] __mutex_lock.isra.7+0x310/0x420<br /> [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core]<br /> [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core]<br /> [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core]<br /> [20976.261079] ib_register_device+0x40d/0x580 [ib_core]<br /> [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma]<br /> [20976.281409] irdma_probe+0x2c1/0x360 [irdma]<br /> [20976.285691] auxiliary_bus_probe+0x45/0x70<br /> [20976.289790] really_probe+0x1f2/0x480<br /> [20976.298509] driver_probe_device+0x49/0xc0<br /> [20976.302609] bus_for_each_drv+0x79/0xc0<br /> [20976.306448] __device_attach+0xdc/0x160<br /> [20976.310286] bus_probe_device+0x9d/0xb0<br /> [20976.314128] device_add+0x43c/0x890<br /> [20976.321287] __auxiliary_device_add+0x43/0x60<br /> [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice]<br /> [20976.330109] ice_service_task+0xd0c/0xed0 [ice]<br /> [20976.342591] process_one_work+0x1a7/0x360<br /> [20976.350536] worker_thread+0x30/0x390<br /> [20976.358128] kthread+0x10a/0x120<br /> [20976.365547] ret_from_fork+0x1f/0x40<br /> ...<br /> [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084<br /> [20976.446469] Call Trace:<br /> [20976.448921] __schedule+0x2d1/0x830<br /> [20976.452414] schedule+0x35/0xa0<br /> [20976.455559] schedule_preempt_disabled+0xa/0x10<br /> [20976.460090] __mutex_lock.isra.7+0x310/0x420<br /> [20976.464364] device_del+0x36/0x3c0<br /> [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice]<br /> [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice]<br /> [20976.477288] notifier_call_chain+0x47/0x70<br /> [20976.481386] __netdev_upper_dev_link+0x18b/0x280<br /> [20976.489845] bond_enslave+0xe05/0x1790 [bonding]<br /> [20976.494475] do_setlink+0x336/0xf50<br /> [20976.502517] __rtnl_newlink+0x529/0x8b0<br /> [20976.543441] rtnl_newlink+0x43/0x60<br /> [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360<br /> [20976.559238] netlink_rcv_skb+0x4c/0x120<br /> [20976.563079] netlink_unicast+0x196/0x230<br /> [20976.567005] netlink_sendmsg+0x204/0x3d0<br /> [20976.570930] sock_sendmsg+0x4c/0x50<br /> [20976.574423] ____sys_sendmsg+0x1eb/0x250<br /> [20976.586807] ___sys_sendmsg+0x7c/0xc0<br /> [20976.606353] __sys_sendmsg+0x57/0xa0<br /> [20976.609930] do_syscall_64+0x5b/0x1a0<br /> [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> <br /> 1. Command &amp;#39;ip link ... set nomaster&amp;#39; causes that ice_plug_aux_dev()<br /> is called from ice_service_task() context, aux device is created<br /> and associated device-&gt;lock is taken.<br /> 2. Command &amp;#39;ip link ... set master...&amp;#39; calls ice&amp;#39;s notifier under<br /> RTNL lock and that notifier calls ice_unplug_aux_dev(). That<br /> function tries to take aux device-&gt;lock but this is already taken<br /> by ice_plug_aux_dev() in step 1<br /> 3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already<br /> taken in step 2<br /> 4. Dead-lock<br /> <br /> The patch fixes this issue by following changes:<br /> - Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev()<br /> call in ice_service_task()<br /> - The bit is checked in ice_clear_rdma_cap() and only if it is not set<br /> then ice_unplug_aux_dev() is called. If it is set (in other words<br /> plugging of aux device was requested and ice_plug_aux_dev() is<br /> potentially running) then the function only clears the<br /> ---truncated---