Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix overflow check in adjust_jmp_off()<br /> <br /> adjust_jmp_off() incorrectly used the insn-&gt;imm field for all overflow check,<br /> which is incorrect as that should only be done or the BPF_JMP32 | BPF_JA case,<br /> not the general jump instruction case. Fix it by using insn-&gt;off for overflow<br /> check in the general case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv, bpf: Fix out-of-bounds issue when preparing trampoline image<br /> <br /> We get the size of the trampoline image during the dry run phase and<br /> allocate memory based on that size. The allocated image will then be<br /> populated with instructions during the real patch phase. But after<br /> commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im`<br /> argument is inconsistent in the dry run and real patch phase. This may<br /> cause emit_imm in RV64 to generate a different number of instructions<br /> when generating the &amp;#39;im&amp;#39; address, potentially causing out-of-bounds<br /> issues. Let&amp;#39;s emit the maximum number of instructions for the "im"<br /> address during dry run to fix this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: wow: fix GTK offload H2C skbuff issue<br /> <br /> We mistakenly put skb too large and that may exceed skb-&gt;end.<br /> Therefore, we fix it.<br /> <br /> skbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev:<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:192!<br /> invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 4747 Comm: kworker/u4:44 Tainted: G O 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e<br /> Hardware name: HP Meep/Meep, BIOS Google_Meep.11297.262.0 03/18/2021<br /> Workqueue: events_unbound async_run_entry_fn<br /> RIP: 0010:skb_panic+0x5d/0x60<br /> Code: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 56 53 41 53 ff b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44<br /> RSP: 0018:ffffaa700144bad0 EFLAGS: 00010282<br /> RAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900<br /> RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001<br /> RBP: ffffaa700144bae0 R08: 0000000000000000 R09: ffffaa700144b920<br /> R10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010<br /> R13: 0000000000000000 R14: ffffffffbb8f8b63 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8fba7bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> ? __die_body+0x1f/0x70<br /> ? die+0x3d/0x60<br /> ? do_trap+0xa4/0x110<br /> ? skb_panic+0x5d/0x60<br /> ? do_error_trap+0x6d/0x90<br /> ? skb_panic+0x5d/0x60<br /> ? handle_invalid_op+0x30/0x40<br /> ? skb_panic+0x5d/0x60<br /> ? exc_invalid_op+0x3c/0x50<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? skb_panic+0x5d/0x60<br /> skb_put+0x49/0x50<br /> rtw89_fw_h2c_wow_gtk_ofld+0xbd/0x220 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]<br /> rtw89_wow_resume+0x31f/0x540 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]<br /> rtw89_ops_resume+0x2b/0xa0 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5]<br /> ieee80211_reconfig+0x84/0x13e0 [mac80211 818a894e3b77da6298269c59ed7cdff065a4ed52]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> ? dev_printk_emit+0x51/0x70<br /> ? _dev_info+0x6e/0x90<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> wiphy_resume+0x89/0x180 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d]<br /> dpm_run_callback+0x3c/0x140<br /> device_resume+0x1f9/0x3c0<br /> ? __pfx_dpm_watchdog_handler+0x10/0x10<br /> async_resume+0x1d/0x30<br /> async_run_entry_fn+0x29/0xd0<br /> process_scheduled_works+0x1d8/0x3d0<br /> worker_thread+0x1fc/0x2f0<br /> kthread+0xed/0x110<br /> ? __pfx_worker_thread+0x10/0x10<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x38/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> Modules linked in: ccm 8021q r8153_ecm cdc_ether usbnet r8152 mii dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc uinput rfcomm cmac algif_hash rtw89_8922ae(O) algif_skcipher rtw89_8922a(O) af_alg rtw89_pci(O) rtw89_core(O) btusb(O) snd_soc_sst_bxt_da7219_max98357a btbcm(O) snd_soc_hdac_hdmi btintel(O) snd_soc_intel_hda_dsp_common snd_sof_probes btrtl(O) btmtk(O) snd_hda_codec_hdmi snd_soc_dmic uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_sof_pci_intel_apl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda soundwire_intel soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp mac80211 snd_soc_acpi_intel_match snd_soc_acpi snd_sof snd_sof_utils soundwire_bus snd_soc_max98357a snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_da7219 snd_hda_codec snd_hwdep snd_hda_core veth ip6table_nat xt_MASQUERADE xt_cgroup fuse bluetooth ecdh_generic<br /> cfg80211 ecc<br /> gsmi: Log Shutdown <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix bogus checksum computation in udf_rename()<br /> <br /> Syzbot reports uninitialized memory access in udf_rename() when updating<br /> checksum of &amp;#39;..&amp;#39; directory entry of a moved directory. This is indeed<br /> true as we pass on-stack diriter.fi to the udf_update_tag() and because<br /> that has only struct fileIdentDesc included in it and not the impUse or<br /> name fields, the checksumming function is going to checksum random stack<br /> contents beyond the end of the structure. This is actually harmless<br /> because the following udf_fiiter_write_fi() will recompute the checksum<br /> from on-disk buffers where everything is properly included. So all that<br /> is needed is just removing the bogus calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix invalid memory access while processing fragmented packets<br /> <br /> The monitor ring and the reo reinject ring share the same ring mask index.<br /> When the driver receives an interrupt for the reo reinject ring, the<br /> monitor ring is also processed, leading to invalid memory access. Since<br /> monitor support is not yet enabled in ath12k, the ring mask for the monitor<br /> ring should be removed.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG<br /> <br /> When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls<br /> __bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them<br /> the struct bpf_tramp_image *im pointer as an argument in R0.<br /> <br /> The trampoline generation code uses emit_addr_mov_i64() to emit<br /> instructions for moving the bpf_tramp_image address into R0, but<br /> emit_addr_mov_i64() assumes the address to be in the vmalloc() space<br /> and uses only 48 bits. Because bpf_tramp_image is allocated using<br /> kzalloc(), its address can use more than 48-bits, in this case the<br /> trampoline will pass an invalid address to __bpf_tramp_enter/exit()<br /> causing a kernel crash.<br /> <br /> Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()<br /> as it can work with addresses that are greater than 48-bits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l: async: Fix NULL pointer dereference in adding ancillary links<br /> <br /> In v4l2_async_create_ancillary_links(), ancillary links are created for<br /> lens and flash sub-devices. These are sub-device to sub-device links and<br /> if the async notifier is related to a V4L2 device, the source sub-device<br /> of the ancillary link is NULL, leading to a NULL pointer dereference.<br /> Check the notifier&amp;#39;s sd field is non-NULL in<br /> v4l2_async_create_ancillary_links().<br /> <br /> [Sakari Ailus: Reword the subject and commit messages slightly.]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xdp: fix invalid wait context of page_pool_destroy()<br /> <br /> If the driver uses a page pool, it creates a page pool with<br /> page_pool_create().<br /> The reference count of page pool is 1 as default.<br /> A page pool will be destroyed only when a reference count reaches 0.<br /> page_pool_destroy() is used to destroy page pool, it decreases a<br /> reference count.<br /> When a page pool is destroyed, -&gt;disconnect() is called, which is<br /> mem_allocator_disconnect().<br /> This function internally acquires mutex_lock().<br /> <br /> If the driver uses XDP, it registers a memory model with<br /> xdp_rxq_info_reg_mem_model().<br /> The xdp_rxq_info_reg_mem_model() internally increases a page pool<br /> reference count if a memory model is a page pool.<br /> Now the reference count is 2.<br /> <br /> To destroy a page pool, the driver should call both page_pool_destroy()<br /> and xdp_unreg_mem_model().<br /> The xdp_unreg_mem_model() internally calls page_pool_destroy().<br /> Only page_pool_destroy() decreases a reference count.<br /> <br /> If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we<br /> will face an invalid wait context warning.<br /> Because xdp_unreg_mem_model() calls page_pool_destroy() with<br /> rcu_read_lock().<br /> The page_pool_destroy() internally acquires mutex_lock().<br /> <br /> Splat looks like:<br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.10.0-rc6+ #4 Tainted: G W<br /> -----------------------------<br /> ethtool/1806 is trying to lock:<br /> ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 3 locks held by ethtool/1806:<br /> stack backtrace:<br /> CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed<br /> Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7e/0xc0<br /> __lock_acquire+0x1681/0x4de0<br /> ? _printk+0x64/0xe0<br /> ? __pfx_mark_lock.part.0+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> lock_acquire+0x1b3/0x580<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __wake_up_klogd.part.0+0x16/0xc0<br /> ? __pfx_lock_acquire+0x10/0x10<br /> ? dump_stack_lvl+0x91/0xc0<br /> __mutex_lock+0x15c/0x1690<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_prb_read_valid+0x10/0x10<br /> ? mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_llist_add_batch+0x10/0x10<br /> ? console_unlock+0x193/0x1b0<br /> ? lockdep_hardirqs_on+0xbe/0x140<br /> ? __pfx___mutex_lock+0x10/0x10<br /> ? tick_nohz_tick_stopped+0x16/0x90<br /> ? __irq_work_queue_local+0x1e5/0x330<br /> ? irq_work_queue+0x39/0x50<br /> ? __wake_up_klogd.part.0+0x79/0xc0<br /> ? mem_allocator_disconnect+0x73/0x150<br /> mem_allocator_disconnect+0x73/0x150<br /> ? __pfx_mem_allocator_disconnect+0x10/0x10<br /> ? mark_held_locks+0xa5/0xf0<br /> ? rcu_is_watching+0x11/0xb0<br /> page_pool_release+0x36e/0x6d0<br /> page_pool_destroy+0xd7/0x440<br /> xdp_unreg_mem_model+0x1a7/0x2a0<br /> ? __pfx_xdp_unreg_mem_model+0x10/0x10<br /> ? kfree+0x125/0x370<br /> ? bnxt_free_ring.isra.0+0x2eb/0x500<br /> ? bnxt_free_mem+0x5ac/0x2500<br /> xdp_rxq_info_unreg+0x4a/0xd0<br /> bnxt_free_mem+0x1356/0x2500<br /> bnxt_close_nic+0xf0/0x3b0<br /> ? __pfx_bnxt_close_nic+0x10/0x10<br /> ? ethnl_parse_bit+0x2c6/0x6d0<br /> ? __pfx___nla_validate_parse+0x10/0x10<br /> ? __pfx_ethnl_parse_bit+0x10/0x10<br /> bnxt_set_features+0x2a8/0x3e0<br /> __netdev_update_features+0x4dc/0x1370<br /> ? ethnl_parse_bitset+0x4ff/0x750<br /> ? __pfx_ethnl_parse_bitset+0x10/0x10<br /> ? __pfx___netdev_update_features+0x10/0x10<br /> ? mark_held_locks+0xa5/0xf0<br /> ? _raw_spin_unlock_irqrestore+0x42/0x70<br /> ? __pm_runtime_resume+0x7d/0x110<br /> ethnl_set_features+0x32d/0xa20<br /> <br /> To fix this problem, it uses rhashtable_lookup_fast() instead of<br /> rhashtable_lookup() with rcu_read_lock().<br /> Using xa without rcu_read_lock() here is safe.<br /> xa is freed by __xdp_mem_allocator_rcu_free() and this is called by<br /> call_rcu() of mem_xa_remove().<br /> The mem_xa_remove() is called by page_pool_destroy() if a reference<br /> count reaches 0.<br /> The xa is already protected by the reference count mechanism well in the<br /> control plane.<br /> So removing rcu_read_lock() for page_pool_destroy() is safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: Fix napi_skb_cache_put warning<br /> <br /> After the commit bdacf3e34945 ("net: Use nested-BH locking for<br /> napi_alloc_cache.") was merged, the following warning began to appear:<br /> <br /> WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0<br /> <br /> __warn+0x12f/0x340<br /> napi_skb_cache_put+0x82/0x4b0<br /> napi_skb_cache_put+0x82/0x4b0<br /> report_bug+0x165/0x370<br /> handle_bug+0x3d/0x80<br /> exc_invalid_op+0x1a/0x50<br /> asm_exc_invalid_op+0x1a/0x20<br /> __free_old_xmit+0x1c8/0x510<br /> napi_skb_cache_put+0x82/0x4b0<br /> __free_old_xmit+0x1c8/0x510<br /> __free_old_xmit+0x1c8/0x510<br /> __pfx___free_old_xmit+0x10/0x10<br /> <br /> The issue arises because virtio is assuming it&amp;#39;s running in NAPI context<br /> even when it&amp;#39;s not, such as in the netpoll case.<br /> <br /> To resolve this, modify virtnet_poll_tx() to only set NAPI when budget<br /> is available. Same for virtnet_poll_cleantx(), which always assumed that<br /> it was in a NAPI context.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXT<br /> <br /> When loading a EXT program without specifying `attr-&gt;attach_prog_fd`,<br /> the `prog-&gt;aux-&gt;dst_prog` will be null. At this time, calling<br /> resolve_prog_type() anywhere will result in a null pointer dereference.<br /> <br /> Example stack trace:<br /> <br /> [ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004<br /> [ 8.108262] Mem abort info:<br /> [ 8.108384] ESR = 0x0000000096000004<br /> [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 8.108722] SET = 0, FnV = 0<br /> [ 8.108827] EA = 0, S1PTW = 0<br /> [ 8.108939] FSC = 0x04: level 0 translation fault<br /> [ 8.109102] Data abort info:<br /> [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000<br /> [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000<br /> [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 8.112783] Modules linked in:<br /> [ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1<br /> [ 8.113230] Hardware name: linux,dummy-virt (DT)<br /> [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0<br /> [ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8<br /> [ 8.113798] sp : ffff80008283b9f0<br /> [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001<br /> [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000<br /> [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000<br /> [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff<br /> [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720<br /> [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720<br /> [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4<br /> [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f<br /> [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c<br /> [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000<br /> [ 8.114126] Call trace:<br /> [ 8.114159] may_access_direct_pkt_data+0x24/0xa0<br /> [ 8.114202] bpf_check+0x3bc/0x28c0<br /> [ 8.114214] bpf_prog_load+0x658/0xa58<br /> [ 8.114227] __sys_bpf+0xc50/0x2250<br /> [ 8.114240] __arm64_sys_bpf+0x28/0x40<br /> [ 8.114254] invoke_syscall.constprop.0+0x54/0xf0<br /> [ 8.114273] do_el0_svc+0x4c/0xd8<br /> [ 8.114289] el0_svc+0x3c/0x140<br /> [ 8.114305] el0t_64_sync_handler+0x134/0x150<br /> [ 8.114331] el0t_64_sync+0x168/0x170<br /> [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)<br /> [ 8.118672] ---[ end trace 0000000000000000 ]---<br /> <br /> One way to fix it is by forcing `attach_prog_fd` non-empty when<br /> bpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`<br /> API broken which use verifier log to probe prog type and will log<br /> nothing if we reject invalid EXT prog before bpf_check().<br /> <br /> Another way is by adding null check in resolve_prog_type().<br /> <br /> The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to<br /> prog-&gt;aux-&gt;dst_prog-&gt;type only for BPF_PROG_TYPE_EXT") which wanted<br /> to correct type resolution for BPF_PROG_TYPE_TRACING programs. Before<br /> that, the type resolution of BPF_PROG_TYPE_EXT prog actually follows<br /> the logic below:<br /> <br /> prog-&gt;aux-&gt;dst_prog ? prog-&gt;aux-&gt;dst_prog-&gt;type : prog-&gt;type;<br /> <br /> It implies that when EXT program is not yet attached to `dst_prog`,<br /> the prog type should be EXT itself. This code worked fine in the past.<br /> So just keep using it.<br /> <br /> Fix this by returning `prog-&gt;type` for BPF_PROG_TYPE_EXT if `dst_prog`<br /> is not present in resolve_prog_type().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bna: adjust &amp;#39;name&amp;#39; buf size of bna_tcb and bna_ccb structures<br /> <br /> To have enough space to write all possible sprintf() args. Currently<br /> &amp;#39;name&amp;#39; size is 16, but the first &amp;#39;%s&amp;#39; specifier may already need at<br /> least 16 characters, since &amp;#39;bnad-&gt;netdev-&gt;name&amp;#39; is used there.<br /> <br /> For &amp;#39;%d&amp;#39; specifiers, assume that they require:<br /> * 1 char for &amp;#39;tx_id + tx_info-&gt;tcb[i]-&gt;id&amp;#39; sum, BNAD_MAX_TXQ_PER_TX is 8<br /> * 2 chars for &amp;#39;rx_id + rx_info-&gt;rx_ctrl[i].ccb-&gt;id&amp;#39;, BNAD_MAX_RXP_PER_RX<br /> is 16<br /> <br /> And replace sprintf with snprintf.<br /> <br /> Detected using the static analysis tool - Svace.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: virt_wifi: avoid reporting connection success with wrong SSID<br /> <br /> When user issues a connection with a different SSID than the one<br /> virt_wifi has advertised, the __cfg80211_connect_result() will<br /> trigger the warning: WARN_ON(bss_not_found).<br /> <br /> The issue is because the connection code in virt_wifi does not<br /> check the SSID from user space (it only checks the BSSID), and<br /> virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS<br /> even if the SSID is different from the one virt_wifi has advertised.<br /> Eventually cfg80211 won&amp;#39;t be able to find the cfg80211_bss and generate<br /> the warning.<br /> <br /> Fixed it by checking the SSID (from user space) in the connection code.