Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: call disconnect callback before deleting conn<br /> <br /> In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.<br /> <br /> ISO, L2CAP and SCO connections refer to the hci_conn without<br /> hci_conn_get, so disconn_cfm must be called so they can clean up their<br /> conn, otherwise use-after-free occurs.<br /> <br /> ISO:<br /> ==========================================================<br /> iso_sock_connect:880: sk 00000000eabd6557<br /> iso_connect_cis:356: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> ...<br /> iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073<br /> hci_dev_put:1487: hci0 orig refcnt 17<br /> __iso_chan_add:214: conn 00000000b6251073<br /> iso_sock_clear_timer:117: sock 00000000eabd6557 state 3<br /> ...<br /> hci_rx_work:4085: hci0 Event packet<br /> hci_event_packet:7601: hci0: event 0x0f<br /> hci_cmd_status_evt:4346: hci0: opcode 0x0406<br /> hci_cs_disconnect:2760: hci0: status 0x0c<br /> hci_sent_cmd_data:3107: hci0 opcode 0x0406<br /> hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560<br /> hci_conn_unlink:1102: hci0: hcon 000000001696f1fd<br /> hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2<br /> hci_chan_list_flush:2780: hcon 000000001696f1fd<br /> hci_dev_put:1487: hci0 orig refcnt 21<br /> hci_dev_put:1487: hci0 orig refcnt 20<br /> hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c<br /> ... ...<br /> iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557<br /> BUG: kernel NULL pointer dereference, address: 0000000000000668<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014<br /> RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth<br /> ==========================================================<br /> <br /> L2CAP:<br /> ==================================================================<br /> hci_cmd_status_evt:4359: hci0: opcode 0x0406<br /> hci_cs_disconnect:2760: hci0: status 0x0c<br /> hci_sent_cmd_data:3085: hci0 opcode 0x0406<br /> hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585<br /> hci_conn_unlink:1102: hci0: hcon ffff88800c999000<br /> hci_chan_list_flush:2780: hcon ffff88800c999000<br /> hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280<br /> ...<br /> BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]<br /> Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175<br /> <br /> CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5b/0x90<br /> print_report+0xcf/0x670<br /> ? __virt_addr_valid+0xf8/0x180<br /> ? hci_send_acl+0x2d/0x540 [bluetooth]<br /> kasan_report+0xa8/0xe0<br /> ? hci_send_acl+0x2d/0x540 [bluetooth]<br /> hci_send_acl+0x2d/0x540 [bluetooth]<br /> ? __pfx___lock_acquire+0x10/0x10<br /> l2cap_chan_send+0x1fd/0x1300 [bluetooth]<br /> ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]<br /> ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]<br /> ? lock_release+0x1d5/0x3c0<br /> ? mark_held_locks+0x1a/0x90<br /> l2cap_sock_sendmsg+0x100/0x170 [bluetooth]<br /> sock_write_iter+0x275/0x280<br /> ? __pfx_sock_write_iter+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> do_iter_readv_writev+0x176/0x220<br /> ? __pfx_do_iter_readv_writev+0x10/0x10<br /> ? find_held_lock+0x83/0xa0<br /> ? selinux_file_permission+0x13e/0x210<br /> do_iter_write+0xda/0x340<br /> vfs_writev+0x1b4/0x400<br /> ? __pfx_vfs_writev+0x10/0x10<br /> ? __seccomp_filter+0x112/0x750<br /> ? populate_seccomp_data+0x182/0x220<br /> ? __fget_light+0xdf/0x100<br /> ? do_writev+0x19d/0x210<br /> do_writev+0x19d/0x210<br /> ? __pfx_do_writev+0x10/0x10<br /> ? mark_held_locks+0x1a/0x90<br /> do_syscall_64+0x60/0x90<br /> ? lockdep_hardirqs_on_prepare+0x149/0x210<br /> ? do_syscall_64+0x6c/0x90<br /> ? lockdep_hardirqs_on_prepare+0x149/0x210<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7ff45cb23e64<br /> Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89<br /> RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014<br /> RAX: ffffffffffffffda RBX: <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-core: fix dev_pm_qos memleak<br /> <br /> Call dev_pm_qos_hide_latency_tolerance() in the error unwind patch to<br /> avoid following kmemleak:-<br /> <br /> blktests (master) # kmemleak-clear; ./check nvme/044;<br /> blktests (master) # kmemleak-scan ; kmemleak-show<br /> nvme/044 (Test bi-directional authentication) [passed]<br /> runtime 2.111s ... 2.124s<br /> unreferenced object 0xffff888110c46240 (size 96):<br /> comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x25/0x90<br /> [] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100<br /> [] nvme_init_ctrl+0x38e/0x410 [nvme_core]<br /> [] 0xffffffffc05e88b3<br /> [] 0xffffffffc05744cb<br /> [] vfs_write+0xc5/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix skb_copy_ubufs() vs BIG TCP<br /> <br /> David Ahern reported crashes in skb_copy_ubufs() caused by TCP tx zerocopy<br /> using hugepages, and skb length bigger than ~68 KB.<br /> <br /> skb_copy_ubufs() assumed it could copy all payload using up to<br /> MAX_SKB_FRAGS order-0 pages.<br /> <br /> This assumption broke when BIG TCP was able to put up to 512 KB per skb.<br /> <br /> We did not hit this bug at Google because we use CONFIG_MAX_SKB_FRAGS=45<br /> and limit gso_max_size to 180000.<br /> <br /> A solution is to use higher order pages if needed.<br /> <br /> v2: add missing __GFP_COMP, or we leak memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Fix deadloop issue on reading trace_pipe<br /> <br /> Soft lockup occurs when reading file &amp;#39;trace_pipe&amp;#39;:<br /> <br /> watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]<br /> [...]<br /> RIP: 0010:ring_buffer_empty_cpu+0xed/0x170<br /> RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246<br /> RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb<br /> RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218<br /> RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f<br /> R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901<br /> R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000<br /> [...]<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> __find_next_entry+0x1a8/0x4b0<br /> ? peek_next_entry+0x250/0x250<br /> ? down_write+0xa5/0x120<br /> ? down_write_killable+0x130/0x130<br /> trace_find_next_entry_inc+0x3b/0x1d0<br /> tracing_read_pipe+0x423/0xae0<br /> ? tracing_splice_read_pipe+0xcb0/0xcb0<br /> vfs_read+0x16b/0x490<br /> ksys_read+0x105/0x210<br /> ? __ia32_sys_pwrite64+0x200/0x200<br /> ? switch_fpu_return+0x108/0x220<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> Through the vmcore, I found it&amp;#39;s because in tracing_read_pipe(),<br /> ring_buffer_empty_cpu() found some buffer is not empty but then it<br /> cannot read anything due to "rb_num_of_entries() == 0" always true,<br /> Then it infinitely loop the procedure due to user buffer not been<br /> filled, see following code path:<br /> <br /> tracing_read_pipe() {<br /> ... ...<br /> waitagain:<br /> tracing_wait_pipe() // 1. find non-empty buffer here<br /> trace_find_next_entry_inc() // 2. loop here try to find an entry<br /> __find_next_entry()<br /> ring_buffer_empty_cpu(); // 3. find non-empty buffer<br /> peek_next_entry() // 4. but peek always return NULL<br /> ring_buffer_peek()<br /> rb_buffer_peek()<br /> rb_get_reader_page()<br /> // 5. because rb_num_of_entries() == 0 always true here<br /> // then return NULL<br /> // 6. user buffer not been filled so goto &amp;#39;waitgain&amp;#39;<br /> // and eventually leads to an deadloop in kernel!!!<br /> }<br /> <br /> By some analyzing, I found that when resetting ringbuffer, the &amp;#39;entries&amp;#39;<br /> of its pages are not all cleared (see rb_reset_cpu()). Then when reducing<br /> the ringbuffer, and if some reduced pages exist dirty &amp;#39;entries&amp;#39; data, they<br /> will be added into &amp;#39;cpu_buffer-&gt;overrun&amp;#39; (see rb_remove_pages()), which<br /> cause wrong &amp;#39;overrun&amp;#39; count and eventually cause the deadloop issue.<br /> <br /> To fix it, we need to clear every pages in rb_reset_cpu().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd938x: fix missing mbhc init error handling<br /> <br /> MBHC initialisation can fail so add the missing error handling to avoid<br /> dereferencing an error pointer when later configuring the jack:<br /> <br /> Unable to handle kernel paging request at virtual address fffffffffffffff8<br /> <br /> pc : wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]<br /> lr : wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]<br /> <br /> Call trace:<br /> wcd_mbhc_start+0x28/0x380 [snd_soc_wcd_mbhc]<br /> wcd938x_codec_set_jack+0x28/0x48 [snd_soc_wcd938x]<br /> snd_soc_component_set_jack+0x28/0x8c [snd_soc_core]<br /> qcom_snd_wcd_jack_setup+0x7c/0x19c [snd_soc_qcom_common]<br /> sc8280xp_snd_init+0x20/0x2c [snd_soc_sc8280xp]<br /> snd_soc_link_init+0x28/0x90 [snd_soc_core]<br /> snd_soc_bind_card+0x628/0xbfc [snd_soc_core]<br /> snd_soc_register_card+0xec/0x104 [snd_soc_core]<br /> devm_snd_soc_register_card+0x4c/0xa4 [snd_soc_core]<br /> sc8280xp_platform_probe+0xf0/0x108 [snd_soc_sc8280xp]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Check instead of asserting on nested TSC scaling support<br /> <br /> Check for nested TSC scaling support on nested SVM VMRUN instead of<br /> asserting that TSC scaling is exposed to L1 if L1&amp;#39;s MSR_AMD64_TSC_RATIO<br /> has diverged from KVM&amp;#39;s default. Userspace can trigger the WARN at will<br /> by writing the MSR and then updating guest CPUID to hide the feature<br /> (modifying guest CPUID is allowed anytime before KVM_RUN). E.g. hacking<br /> KVM&amp;#39;s state_test selftest to do<br /> <br /> vcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);<br /> vcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);<br /> <br /> after restoring state in a new VM+vCPU yields an endless supply of:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699<br /> nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]<br /> Call Trace:<br /> <br /> enter_svm_guest_mode+0x114/0x560 [kvm_amd]<br /> nested_svm_vmrun+0x260/0x330 [kvm_amd]<br /> vmrun_interception+0x29/0x30 [kvm_amd]<br /> svm_invoke_exit_handler+0x35/0x100 [kvm_amd]<br /> svm_handle_exit+0xe7/0x180 [kvm_amd]<br /> kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]<br /> kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]<br /> __se_sys_ioctl+0x7a/0xc0<br /> __x64_sys_ioctl+0x21/0x30<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x45ca1b<br /> <br /> Note, the nested #VMEXIT path has the same flaw, but needs a different<br /> fix and will be handled separately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> OPP: Fix potential null ptr dereference in dev_pm_opp_get_required_pstate()<br /> <br /> "opp" pointer is dereferenced before the IS_ERR_OR_NULL() check. Fix it by<br /> removing the dereference to cache opp_table and dereference it directly<br /> where opp_table is used.<br /> <br /> This fixes the following smatch warning:<br /> <br /> drivers/opp/core.c:232 dev_pm_opp_get_required_pstate() warn: variable<br /> dereferenced before IS_ERR check &amp;#39;opp&amp;#39; (see line 230)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: don&amp;#39;t dereference mddev after export_rdev()<br /> <br /> Except for initial reference, mddev-&gt;kobject is referenced by<br /> rdev-&gt;kobject, and if the last rdev is freed, there is no guarantee that<br /> mddev is still valid. Hence mddev should not be used anymore after<br /> export_rdev().<br /> <br /> This problem can be triggered by following test for mdadm at very<br /> low rate:<br /> <br /> New file: mdadm/tests/23rdev-lifetime<br /> <br /> devname=${dev0##*/}<br /> devt=`cat /sys/block/$devname/dev`<br /> pid=""<br /> runtime=2<br /> <br /> clean_up_test() {<br /> pill -9 $pid<br /> echo clear &gt; /sys/block/md0/md/array_state<br /> }<br /> <br /> trap &amp;#39;clean_up_test&amp;#39; EXIT<br /> <br /> add_by_sysfs() {<br /> while true; do<br /> echo $devt &gt; /sys/block/md0/md/new_dev<br /> done<br /> }<br /> <br /> remove_by_sysfs(){<br /> while true; do<br /> echo remove &gt; /sys/block/md0/md/dev-${devname}/state<br /> done<br /> }<br /> <br /> echo md0 &gt; /sys/module/md_mod/parameters/new_array || die "create md0 failed"<br /> <br /> add_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> remove_by_sysfs &amp;<br /> pid="$pid $!"<br /> <br /> sleep $runtime<br /> exit 0<br /> <br /> Test cmd:<br /> <br /> ./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime<br /> <br /> Test result:<br /> <br /> general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP<br /> CPU: 0 PID: 1292 Comm: test Tainted: G D W 6.5.0-rc2-00121-g01e55c376936 #562<br /> RIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]<br /> Call Trace:<br /> <br /> mddev_unlock+0x1b6/0x310 [md_mod]<br /> rdev_attr_store+0xec/0x190 [md_mod]<br /> sysfs_kf_write+0x52/0x70<br /> kernfs_fop_write_iter+0x19a/0x2a0<br /> vfs_write+0x3b5/0x770<br /> ksys_write+0x74/0x150<br /> __x64_sys_write+0x22/0x30<br /> do_syscall_64+0x40/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Fix this problem by don&amp;#39;t dereference mddev after export_rdev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: cdc_ncm: Deal with too low values of dwNtbOutMaxSize<br /> <br /> Currently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower than<br /> the calculated "min" value, but greater than zero, the logic sets<br /> tx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB in<br /> cdc_ncm_fill_tx_frame() where all the data is handled.<br /> <br /> For small values of dwNtbOutMaxSize the memory allocated during<br /> alloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due to<br /> how size is aligned at alloc time:<br /> size = SKB_DATA_ALIGN(size);<br /> size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));<br /> Thus we hit the same bug that we tried to squash with<br /> commit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")<br /> <br /> Low values of dwNtbOutMaxSize do not cause an issue presently because at<br /> alloc_skb() time more memory (512b) is allocated than required for the<br /> SKB headers alone (320b), leaving some space (512b - 320b = 192b)<br /> for CDC data (172b).<br /> <br /> However, if more elements (for example 3 x u64 = [24b]) were added to<br /> one of the SKB header structs, say &amp;#39;struct skb_shared_info&amp;#39;,<br /> increasing its original size (320b [320b aligned]) to something larger<br /> (344b [384b aligned]), then suddenly the CDC data (172b) no longer<br /> fits in the spare SKB data area (512b - 384b = 128b).<br /> <br /> Consequently the SKB bounds checking semantics fails and panics:<br /> <br /> skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:113!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:skb_panic net/core/skbuff.c:113 [inline]<br /> RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118<br /> [snip]<br /> Call Trace:<br /> <br /> skb_put+0x151/0x210 net/core/skbuff.c:2047<br /> skb_put_zero include/linux/skbuff.h:2422 [inline]<br /> cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline]<br /> cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308<br /> cdc_ncm_tx_fixup+0xa3/0x100<br /> <br /> Deal with too low values of dwNtbOutMaxSize, clamp it in the range<br /> [USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensure<br /> enough data space is allocated to handle CDC data by making sure<br /> dwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Don&amp;#39;t tx before switchdev is fully configured<br /> <br /> There is possibility that ice_eswitch_port_start_xmit might be<br /> called while some resources are still not allocated which might<br /> cause NULL pointer dereference. Fix this by checking if switchdev<br /> configuration was finished.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: bcm-qspi: return error if neither hif_mspi nor mspi is available<br /> <br /> If neither a "hif_mspi" nor "mspi" resource is present, the driver will<br /> just early exit in probe but still return success. Apart from not doing<br /> anything meaningful, this would then also lead to a null pointer access<br /> on removal, as platform_get_drvdata() would return NULL, which it would<br /> then try to dereference when trying to unregister the spi master.<br /> <br /> Fix this by unconditionally calling devm_ioremap_resource(), as it can<br /> handle a NULL res and will then return a viable ERR_PTR() if we get one.<br /> <br /> The "return 0;" was previously a "goto qspi_resource_err;" where then<br /> ret was returned, but since ret was still initialized to 0 at this place<br /> this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix<br /> use-after-free on unbind"). The issue was not introduced by this commit,<br /> only made more obvious.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: Fix out-of-bounds when setting channels on remove<br /> <br /> If we set channels greater during iavf_remove(), and waiting reset done<br /> would be timeout, then returned with error but changed num_active_queues<br /> directly, that will lead to OOB like the following logs. Because the<br /> num_active_queues is greater than tx/rx_rings[] allocated actually.<br /> <br /> Reproducer:<br /> <br /> [root@host ~]# cat repro.sh<br /> #!/bin/bash<br /> <br /> pf_dbsf="0000:41:00.0"<br /> vf0_dbsf="0000:41:02.0"<br /> g_pids=()<br /> <br /> function do_set_numvf()<br /> {<br /> echo 2 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> echo 0 &gt;/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs<br /> sleep $((RANDOM%3+1))<br /> }<br /> <br /> function do_set_channel()<br /> {<br /> local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/)<br /> [ -z "$nic" ] &amp;&amp; { sleep $((RANDOM%3)) ; return 1; }<br /> ifconfig $nic 192.168.18.5 netmask 255.255.255.0<br /> ifconfig $nic up<br /> ethtool -L $nic combined 1<br /> ethtool -L $nic combined 4<br /> sleep $((RANDOM%3))<br /> }<br /> <br /> function on_exit()<br /> {<br /> local pid<br /> for pid in "${g_pids[@]}"; do<br /> kill -0 "$pid" &amp;&gt;/dev/null &amp;&amp; kill "$pid" &amp;&gt;/dev/null<br /> done<br /> g_pids=()<br /> }<br /> <br /> trap "on_exit; exit" EXIT<br /> <br /> while :; do do_set_numvf ; done &amp;<br /> g_pids+=($!)<br /> while :; do do_set_channel ; done &amp;<br /> g_pids+=($!)<br /> <br /> wait<br /> <br /> Result:<br /> <br /> [ 3506.152887] iavf 0000:41:02.0: Removing device<br /> [ 3510.400799] ==================================================================<br /> [ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536<br /> [ 3510.400823]<br /> [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1<br /> [ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021<br /> [ 3510.400835] Call Trace:<br /> [ 3510.400851] dump_stack+0x71/0xab<br /> [ 3510.400860] print_address_description+0x6b/0x290<br /> [ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400868] kasan_report+0x14a/0x2b0<br /> [ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf]<br /> [ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf]<br /> [ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf]<br /> [ 3510.400891] ? wait_woken+0x1d0/0x1d0<br /> [ 3510.400895] ? notifier_call_chain+0xc1/0x130<br /> [ 3510.400903] pci_device_remove+0xa8/0x1f0<br /> [ 3510.400910] device_release_driver_internal+0x1c6/0x460<br /> [ 3510.400916] pci_stop_bus_device+0x101/0x150<br /> [ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 3510.400924] pci_iov_remove_virtfn+0x187/0x420<br /> [ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10<br /> [ 3510.400929] ? pci_get_subsys+0x90/0x90<br /> [ 3510.400932] sriov_disable+0xed/0x3e0<br /> [ 3510.400936] ? bus_find_device+0x12d/0x1a0<br /> [ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e]<br /> [ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e]<br /> [ 3510.400968] ? pci_get_device+0x7c/0x90<br /> [ 3510.400970] ? pci_get_subsys+0x90/0x90<br /> [ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210<br /> [ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e]<br /> [ 3510.401001] sriov_numvfs_store+0x214/0x290<br /> [ 3510.401005] ? sriov_totalvfs_show+0x30/0x30<br /> [ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10<br /> [ 3510.401011] ? __check_object_size+0x15a/0x350<br /> [ 3510.401018] kernfs_fop_write+0x280/0x3f0<br /> [ 3510.401022] vfs_write+0x145/0x440<br /> [ 3510.401025] ksys_write+0xab/0x160<br /> [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0<br /> [ 3510.401031] ? fput_many+0x1a/0x120<br /> [ 3510.401032] ? filp_close+0xf0/0x130<br /> [ 3510.401038] do_syscall_64+0xa0/0x370<br /> [ 3510.401041] ? page_fault+0x8/0x30<br /> [ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca<br /> [ 3510.401073] RIP: 0033:0x7f3a9bb842c0<br /> [ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 3d <br /> ---truncated---