Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: port100: fix use-after-free in port100_send_complete<br /> <br /> Syzbot reported UAF in port100_send_complete(). The root case is in<br /> missing usb_kill_urb() calls on error handling path of -&gt;probe function.<br /> <br /> port100_send_complete() accesses devm allocated memory which will be<br /> freed on probe failure. We should kill this urbs before returning an<br /> error from probe function to prevent reported use-after-free<br /> <br /> Fail log:<br /> <br /> BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935<br /> Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26<br /> ...<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 /> port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935<br /> __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670<br /> <br /> ...<br /> <br /> Allocated by task 1255:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track mm/kasan/common.c:45 [inline]<br /> set_alloc_info mm/kasan/common.c:436 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:515 [inline]<br /> ____kasan_kmalloc mm/kasan/common.c:474 [inline]<br /> __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524<br /> alloc_dr drivers/base/devres.c:116 [inline]<br /> devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823<br /> devm_kzalloc include/linux/device.h:209 [inline]<br /> port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502<br /> <br /> Freed by task 1255:<br /> kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38<br /> kasan_set_track+0x21/0x30 mm/kasan/common.c:45<br /> kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370<br /> ____kasan_slab_free mm/kasan/common.c:366 [inline]<br /> ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328<br /> kasan_slab_free include/linux/kasan.h:236 [inline]<br /> __cache_free mm/slab.c:3437 [inline]<br /> kfree+0xf8/0x2b0 mm/slab.c:3794<br /> release_nodes+0x112/0x1a0 drivers/base/devres.c:501<br /> devres_release_all+0x114/0x190 drivers/base/devres.c:530<br /> really_probe+0x626/0xcc0 drivers/base/dd.c:670

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 /> drm/amdgpu: bypass tiling flag check in virtual display case (v2)<br /> <br /> vkms leverages common amdgpu framebuffer creation, and<br /> also as it does not support FB modifier, there is no need<br /> to check tiling flags when initing framebuffer when virtual<br /> display is enabled.<br /> <br /> This can fix below calltrace:<br /> <br /> amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier<br /> WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]<br /> <br /> v2: check adev-&gt;enable_virtual_display instead as vkms can be<br /> enabled in bare metal as well.

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