Vulnerabilities

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 /> iomap: Fix possible overflow condition in iomap_write_delalloc_scan<br /> <br /> folio_next_index() returns an unsigned long value which left shifted<br /> by PAGE_SHIFT could possibly cause an overflow on 32-bit system. Instead<br /> use folio_pos(folio) + folio_size(folio), which does this correctly.

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---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qedf: Fix NULL dereference in error handling<br /> <br /> Smatch reported:<br /> <br /> drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()<br /> warn: missing unwind goto?<br /> <br /> At this point in the function, nothing has been allocated so we can return<br /> directly. In particular the "qedf-&gt;global_queues" have not been allocated<br /> so calling qedf_free_global_queues() will lead to a NULL dereference when<br /> we check if (!gl[i]) and "gl" is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before init<br /> <br /> blk-iocost sometimes causes the following crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000e0<br /> ...<br /> RIP: 0010:_raw_spin_lock+0x17/0x30<br /> Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00<br /> RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001<br /> RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0<br /> RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003<br /> R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000<br /> R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600<br /> FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0<br /> Call Trace:<br /> <br /> ioc_weight_write+0x13d/0x410<br /> cgroup_file_write+0x7a/0x130<br /> kernfs_fop_write_iter+0xf5/0x170<br /> vfs_write+0x298/0x370<br /> ksys_write+0x5f/0xb0<br /> __x64_sys_write+0x1b/0x20<br /> do_syscall_64+0x3d/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> This happens because iocg-&gt;ioc is NULL. The field is initialized by<br /> ioc_pd_init() and never cleared. The NULL deref is caused by<br /> blkcg_activate_policy() installing blkg_policy_data before initializing it.<br /> <br /> blkcg_activate_policy() was doing the following:<br /> <br /> 1. Allocate pd&amp;#39;s for all existing blkg&amp;#39;s and install them in blkg-&gt;pd[].<br /> 2. Initialize all pd&amp;#39;s.<br /> 3. Online all pd&amp;#39;s.<br /> <br /> blkcg_activate_policy() only grabs the queue_lock and may release and<br /> re-acquire the lock as allocation may need to sleep. ioc_weight_write()<br /> grabs blkcg-&gt;lock and iterates all its blkg&amp;#39;s. The two can race and if<br /> ioc_weight_write() runs during #1 or between #1 and #2, it can encounter a<br /> pd which is not initialized yet, leading to crash.<br /> <br /> The crash can be reproduced with the following script:<br /> <br /> #!/bin/bash<br /> <br /> echo +io &gt; /sys/fs/cgroup/cgroup.subtree_control<br /> systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct<br /> echo 100 &gt; /sys/fs/cgroup/system.slice/io.weight<br /> bash -c "echo &amp;#39;8:0 enable=1&amp;#39; &gt; /sys/fs/cgroup/io.cost.qos" &amp;<br /> sleep .2<br /> echo 100 &gt; /sys/fs/cgroup/system.slice/io.weight<br /> <br /> with the following patch applied:<br /> <br /> &gt; diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c<br /> &gt; index fc49be622e05..38d671d5e10c 100644<br /> &gt; --- a/block/blk-cgroup.c<br /> &gt; +++ b/block/blk-cgroup.c<br /> &gt; @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)<br /> &gt; pd-&gt;online = false;<br /> &gt; }<br /> &gt;<br /> &gt; + if (system_state == SYSTEM_RUNNING) {<br /> &gt; + spin_unlock_irq(&amp;q-&gt;queue_lock);<br /> &gt; + ssleep(1);<br /> &gt; + spin_lock_irq(&amp;q-&gt;queue_lock);<br /> &gt; + }<br /> &gt; +<br /> &gt; /* all allocated, init in the same order */<br /> &gt; if (pol-&gt;pd_init_fn)<br /> &gt; list_for_each_entry_reverse(blkg, &amp;q-&gt;blkg_list, q_node)<br /> <br /> I don&amp;#39;t see a reason why all pd&amp;#39;s should be allocated, initialized and<br /> onlined together. The only ordering requirement is that parent blkgs to be<br /> initialized and onlined before children, which is guaranteed from the<br /> walking order. Let&amp;#39;s fix the bug by allocating, initializing and onlining pd<br /> for each blkg and holding blkcg-&gt;lock over initialization and onlining. This<br /> ensures that an installed blkg is always fully initialized and onlined<br /> removing the the race window.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix a possible null-pointer dereference in ni_clear()<br /> <br /> In a previous commit c1006bd13146, ni-&gt;mi.mrec in ni_write_inode()<br /> could be NULL, and thus a NULL check is added for this variable.<br /> <br /> However, in the same call stack, ni-&gt;mi.mrec can be also dereferenced<br /> in ni_clear():<br /> <br /> ntfs_evict_inode(inode)<br /> ni_write_inode(inode, ...)<br /> ni = ntfs_i(inode);<br /> is_rec_inuse(ni-&gt;mi.mrec) -&gt; Add a NULL check by previous commit<br /> ni_clear(ntfs_i(inode))<br /> is_rec_inuse(ni-&gt;mi.mrec) -&gt; No check<br /> <br /> Thus, a possible null-pointer dereference may exist in ni_clear().<br /> To fix it, a NULL check is added in this function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Fix leak of dev tracker<br /> <br /> At the stage of direction checks, the netdev reference tracker is<br /> already initialized, but released with wrong *_put() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/srpt: Add a check for valid &amp;#39;mad_agent&amp;#39; pointer<br /> <br /> When unregistering MAD agent, srpt module has a non-null check<br /> for &amp;#39;mad_agent&amp;#39; pointer before invoking ib_unregister_mad_agent().<br /> This check can pass if &amp;#39;mad_agent&amp;#39; variable holds an error value.<br /> The &amp;#39;mad_agent&amp;#39; can have an error value for a short window when<br /> srpt_add_one() and srpt_remove_one() is executed simultaneously.<br /> <br /> In srpt module, added a valid pointer check for &amp;#39;sport-&gt;mad_agent&amp;#39;<br /> before unregistering MAD agent.<br /> <br /> This issue can hit when RoCE driver unregisters ib_device<br /> <br /> Stack Trace:<br /> ------------<br /> BUG: kernel NULL pointer dereference, address: 000000000000004d<br /> PGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P<br /> Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020<br /> Workqueue: bnxt_re bnxt_re_task [bnxt_re]<br /> RIP: 0010:_raw_spin_lock_irqsave+0x19/0x40<br /> Call Trace:<br /> ib_unregister_mad_agent+0x46/0x2f0 [ib_core]<br /> IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready<br /> ? __schedule+0x20b/0x560<br /> srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]<br /> srpt_remove_one+0x20/0x150 [ib_srpt]<br /> remove_client_context+0x88/0xd0 [ib_core]<br /> bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex<br /> disable_device+0x8a/0x160 [ib_core]<br /> bond0: active interface up!<br /> ? kernfs_name_hash+0x12/0x80<br /> (NULL device *): Bonding Info Received: rdev: 000000006c0b8247<br /> __ib_unregister_device+0x42/0xb0 [ib_core]<br /> (NULL device *): Master: mode: 4 num_slaves:2<br /> ib_unregister_device+0x22/0x30 [ib_core]<br /> (NULL device *): Slave: id: 105069936 name:p2p1 link:0 state:0<br /> bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]<br /> bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]