Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix memleak of md thread<br /> <br /> In raid10_run(), if setup_conf() succeed and raid10_run() failed before<br /> setting &amp;#39;mddev-&gt;thread&amp;#39;, then in the error path &amp;#39;conf-&gt;thread&amp;#39; is not<br /> freed.<br /> <br /> Fix the problem by setting &amp;#39;mddev-&gt;thread&amp;#39; right after setup_conf().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type<br /> <br /> spi_nor_set_erase_type() was used either to set or to mask out an erase<br /> type. When we used it to mask out an erase type a shift-out-of-bounds<br /> was hit:<br /> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24<br /> shift exponent 4294967295 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> The setting of the size_{shift, mask} and of the opcode are unnecessary<br /> when the erase size is zero, as throughout the code just the erase size<br /> is considered to determine whether an erase type is supported or not.<br /> Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF<br /> is an unused opcode. Thus when masking out an erase type, just set the<br /> erase size to zero. This will fix the shift-out-of-bounds.<br /> <br /> [ta: refine changes, new commit message, fix compilation error]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration<br /> <br /> Fix a goof where KVM tries to grab source vCPUs from the destination VM<br /> when doing intrahost migration. Grabbing the wrong vCPU not only hoses<br /> the guest, it also crashes the host due to the VMSA pointer being left<br /> NULL.<br /> <br /> BUG: unable to handle page fault for address: ffffe38687000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO 6.5.0-smp--fff2e47e6c3b-next #151<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023<br /> RIP: 0010:__free_pages+0x15/0xd0<br /> RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100<br /> RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000<br /> RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000<br /> R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> sev_free_vcpu+0xcb/0x110 [kvm_amd]<br /> svm_vcpu_free+0x75/0xf0 [kvm_amd]<br /> kvm_arch_vcpu_destroy+0x36/0x140 [kvm]<br /> kvm_destroy_vcpus+0x67/0x100 [kvm]<br /> kvm_arch_destroy_vm+0x161/0x1d0 [kvm]<br /> kvm_put_kvm+0x276/0x560 [kvm]<br /> kvm_vm_release+0x25/0x30 [kvm]<br /> __fput+0x106/0x280<br /> ____fput+0x12/0x20<br /> task_work_run+0x86/0xb0<br /> do_exit+0x2e3/0x9c0<br /> do_group_exit+0xb1/0xc0<br /> __x64_sys_exit_group+0x1b/0x20<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CR2: ffffe38687000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix memory leak after finding block group with super blocks<br /> <br /> At exclude_super_stripes(), if we happen to find a block group that has<br /> super blocks mapped to it and we are on a zoned filesystem, we error out<br /> as this is not supposed to happen, indicating either a bug or maybe some<br /> memory corruption for example. However we are exiting the function without<br /> freeing the memory allocated for the logical address of the super blocks.<br /> Fix this by freeing the logical address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: intel: quark_dts: fix error pointer dereference<br /> <br /> If alloc_soc_dts() fails, then we can just return. Trying to free<br /> "soc_dts" will lead to an Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before inode lookup during the ino lookup ioctl<br /> <br /> During the ino lookup ioctl we can end up calling btrfs_iget() to get an<br /> inode reference while we are holding on a root&amp;#39;s btree. If btrfs_iget()<br /> needs to lookup the inode from the root&amp;#39;s btree, because it&amp;#39;s not<br /> currently loaded in memory, then it will need to lock another or the<br /> same path in the same root btree. This may result in a deadlock and<br /> trigger the following lockdep splat:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted<br /> ------------------------------------------------------<br /> syz-executor277/5012 is trying to acquire lock:<br /> ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> but task is already holding lock:<br /> ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302<br /> btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955<br /> btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline]<br /> btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338<br /> btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline]<br /> open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494<br /> btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154<br /> btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> fc_mount fs/namespace.c:1112 [inline]<br /> vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142<br /> btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> do_new_mount+0x28f/0xae0 fs/namespace.c:3335<br /> do_mount fs/namespace.c:3675 [inline]<br /> __do_sys_mount fs/namespace.c:3884 [inline]<br /> __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> -&gt; #0 (btrfs-tree-01){++++}-{3:3}:<br /> check_prev_add kernel/locking/lockdep.c:3142 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3261 [inline]<br /> validate_chain kernel/locking/lockdep.c:3876 [inline]<br /> __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144<br /> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline]<br /> btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281<br /> btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline]<br /> btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154<br /> btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412<br /> btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline]<br /> btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716<br /> btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline]<br /> btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105<br /> btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> other info <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tuners: qt1010: replace BUG_ON with a regular error<br /> <br /> BUG_ON is unnecessary here, and in addition it confuses smatch.<br /> Replacing this with an error return help resolve this smatch<br /> warning:<br /> <br /> drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow &amp;#39;i2c_data&amp;#39; 34

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Address KCSAN report on bpf_lru_list<br /> <br /> KCSAN reported a data-race when accessing node-&gt;ref.<br /> Although node-&gt;ref does not have to be accurate,<br /> take this chance to use a more common READ_ONCE() and WRITE_ONCE()<br /> pattern instead of data_race().<br /> <br /> There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().<br /> This patch also adds bpf_lru_node_clear_ref() to do the<br /> WRITE_ONCE(node-&gt;ref, 0) also.<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elem<br /> <br /> write to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:<br /> __bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]<br /> __bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]<br /> __bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240<br /> bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]<br /> bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]<br /> bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499<br /> prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]<br /> __htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316<br /> bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313<br /> bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687<br /> bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534<br /> __sys_bpf+0x338/0x810<br /> __do_sys_bpf kernel/bpf/syscall.c:5096 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5094 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:<br /> bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]<br /> __htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332<br /> bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313<br /> bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200<br /> generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687<br /> bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534<br /> __sys_bpf+0x338/0x810<br /> __do_sys_bpf kernel/bpf/syscall.c:5096 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5094 [inline]<br /> __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x01 -&gt; 0x00<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: av7110: prevent underflow in write_ts_to_decoder()<br /> <br /> The buf[4] value comes from the user via ts_play(). It is a value in<br /> the u8 range. The final length we pass to av7110_ipack_instant_repack()<br /> is "len - (buf[4] + 1) - 4" so add a check to ensure that the length is<br /> not negative. It&amp;#39;s not clear that passing a negative len value does<br /> anything bad necessarily, but it&amp;#39;s not best practice.<br /> <br /> With the new bounds checking the "if (!len)" condition is no longer<br /> possible or required so remove that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace<br /> <br /> A received TKIP key may be up to 32 bytes because it may contain<br /> MIC rx/tx keys too. These are not used by iwl and copying these<br /> over overflows the iwl_keyinfo.key field.<br /> <br /> Add a check to not copy more data to iwl_keyinfo.key then will fit.<br /> <br /> This fixes backtraces like this one:<br /> <br /> memcpy: detected field-spanning write (size 32) of single field "sta_cmd.key.key" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16)<br /> WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]<br /> <br /> Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017<br /> RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]<br /> <br /> Call Trace:<br /> <br /> iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]<br /> iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]<br /> drv_set_key+0xa4/0x1b0 [mac80211]<br /> ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]<br /> ieee80211_key_replace+0x22d/0x8e0 [mac80211]<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: imx: disable Ageing Timer interrupt request irq<br /> <br /> There maybe pending USR interrupt before requesting irq, however<br /> uart_add_one_port has not executed, so there will be kernel panic:<br /> [ 0.795668] Unable to handle kernel NULL pointer dereference at virtual addre<br /> ss 0000000000000080<br /> [ 0.802701] Mem abort info:<br /> [ 0.805367] ESR = 0x0000000096000004<br /> [ 0.808950] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.814033] SET = 0, FnV = 0<br /> [ 0.816950] EA = 0, S1PTW = 0<br /> [ 0.819950] FSC = 0x04: level 0 translation fault<br /> [ 0.824617] Data abort info:<br /> [ 0.827367] ISV = 0, ISS = 0x00000004<br /> [ 0.831033] CM = 0, WnR = 0<br /> [ 0.833866] [0000000000000080] user address but active_mm is swapper<br /> [ 0.839951] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 0.845953] Modules linked in:<br /> [ 0.848869] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.1+g56321e101aca #1<br /> [ 0.855617] Hardware name: Freescale i.MX8MP EVK (DT)<br /> [ 0.860452] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.867117] pc : __imx_uart_rxint.constprop.0+0x11c/0x2c0<br /> [ 0.872283] lr : imx_uart_int+0xf8/0x1ec<br /> <br /> The issue only happends in the inmate linux when Jailhouse hypervisor<br /> enabled. The test procedure is:<br /> while true; do<br /> jailhouse enable imx8mp.cell<br /> jailhouse cell linux xxxx<br /> sleep 10<br /> jailhouse cell destroy 1<br /> jailhouse disable<br /> sleep 5<br /> done<br /> <br /> And during the upper test, press keys to the 2nd linux console.<br /> When `jailhouse cell destroy 1`, the 2nd linux has no chance to put<br /> the uart to a quiese state, so USR1/2 may has pending interrupts. Then<br /> when `jailhosue cell linux xx` to start 2nd linux again, the issue<br /> trigger.<br /> <br /> In order to disable irqs before requesting them, both UCR1 and UCR2 irqs<br /> should be disabled, so here fix that, disable the Ageing Timer interrupt<br /> in UCR2 as UCR1 does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fortify the spinlock against deadlock by interrupt<br /> <br /> In the function ieee80211_tx_dequeue() there is a particular locking<br /> sequence:<br /> <br /> begin:<br /> spin_lock(&amp;local-&gt;queue_stop_reason_lock);<br /> q_stopped = local-&gt;queue_stop_reasons[q];<br /> spin_unlock(&amp;local-&gt;queue_stop_reason_lock);<br /> <br /> However small the chance (increased by ftracetest), an asynchronous<br /> interrupt can occur in between of spin_lock() and spin_unlock(),<br /> and the interrupt routine will attempt to lock the same<br /> &amp;local-&gt;queue_stop_reason_lock again.<br /> <br /> This will cause a costly reset of the CPU and the wifi device or an<br /> altogether hang in the single CPU and single core scenario.<br /> <br /> The only remaining spin_lock(&amp;local-&gt;queue_stop_reason_lock) that<br /> did not disable interrupts was patched, which should prevent any<br /> deadlocks on the same CPU/core and the same wifi device.<br /> <br /> This is the probable trace of the deadlock:<br /> <br /> kernel: ================================<br /> kernel: WARNING: inconsistent lock state<br /> kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W<br /> kernel: --------------------------------<br /> kernel: inconsistent {IN-SOFTIRQ-W} -&gt; {SOFTIRQ-ON-W} usage.<br /> kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:<br /> kernel: ffff9d6190779478 (&amp;local-&gt;queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40<br /> kernel: {IN-SOFTIRQ-W} state was registered at:<br /> kernel: lock_acquire+0xc7/0x2d0<br /> kernel: _raw_spin_lock+0x36/0x50<br /> kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]<br /> kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]<br /> kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]<br /> kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]<br /> kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]<br /> kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]<br /> kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]<br /> kernel: dev_hard_start_xmit+0xb5/0x260<br /> kernel: __dev_queue_xmit+0xdbe/0x1200<br /> kernel: neigh_resolve_output+0x166/0x260<br /> kernel: ip_finish_output2+0x216/0xb80<br /> kernel: __ip_finish_output+0x2a4/0x4d0<br /> kernel: ip_finish_output+0x2d/0xd0<br /> kernel: ip_output+0x82/0x2b0<br /> kernel: ip_local_out+0xec/0x110<br /> kernel: igmpv3_sendpack+0x5c/0x90<br /> kernel: igmp_ifc_timer_expire+0x26e/0x4e0<br /> kernel: call_timer_fn+0xa5/0x230<br /> kernel: run_timer_softirq+0x27f/0x550<br /> kernel: __do_softirq+0xb4/0x3a4<br /> kernel: irq_exit_rcu+0x9b/0xc0<br /> kernel: sysvec_apic_timer_interrupt+0x80/0xa0<br /> kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30<br /> kernel: _raw_spin_unlock_irqrestore+0x3f/0x70<br /> kernel: free_to_partial_list+0x3d6/0x590<br /> kernel: __slab_free+0x1b7/0x310<br /> kernel: kmem_cache_free+0x52d/0x550<br /> kernel: putname+0x5d/0x70<br /> kernel: do_sys_openat2+0x1d7/0x310<br /> kernel: do_sys_open+0x51/0x80<br /> kernel: __x64_sys_openat+0x24/0x30<br /> kernel: do_syscall_64+0x5c/0x90<br /> kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> kernel: irq event stamp: 5120729<br /> kernel: hardirqs last enabled at (5120729): [] trace_graph_return+0xd6/0x120<br /> kernel: hardirqs last disabled at (5120728): [] trace_graph_return+0xf0/0x120<br /> kernel: softirqs last enabled at (5069900): [] return_to_handler+0x0/0x40<br /> kernel: softirqs last disabled at (5067555): [] return_to_handler+0x0/0x40<br /> kernel:<br /> other info that might help us debug this:<br /> kernel: Possible unsafe locking scenario:<br /> kernel: CPU0<br /> kernel: ----<br /> kernel: lock(&amp;local-&gt;queue_stop_reason_lock);<br /> kernel: <br /> kernel: lock(&amp;local-&gt;queue_stop_reason_lock);<br /> kernel:<br /> *** DEADLOCK ***<br /> kernel: 8 locks held by kworker/5:0/25656:<br /> kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530<br /> kernel: #1: ffffb1ef4637fe68 ((work_completion)(&amp;local-&gt;restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530<br /> kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40<br /> kernel: #3: ffff9d619<br /> ---truncated---