Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: CT: Fix cleanup of CT before cleanup of TC ct rules<br /> <br /> CT cleanup assumes that all tc rules were deleted first, and so<br /> is free to delete the CT shared resources (e.g the dr_action<br /> fwd_action which is shared for all tuples). But currently for<br /> uplink, this is happens in reverse, causing the below trace.<br /> <br /> CT cleanup is called from:<br /> mlx5e_cleanup_rep_tx()-&gt;mlx5e_cleanup_uplink_rep_tx()-&gt;<br /> mlx5e_rep_tc_cleanup()-&gt;mlx5e_tc_esw_cleanup()-&gt;<br /> mlx5_tc_ct_clean()<br /> <br /> Only afterwards, tc cleanup is called from:<br /> mlx5e_cleanup_rep_tx()-&gt;mlx5e_tc_ht_cleanup()<br /> which would have deleted all the tc ct rules, and so delete<br /> all the offloaded tuples.<br /> <br /> Fix this reversing the order of init and on cleanup, which<br /> will result in tc cleanup then ct cleanup.<br /> <br /> [ 9443.593347] WARNING: CPU: 2 PID: 206774 at drivers/net/ethernet/mellanox/mlx5/core/steering/dr_action.c:1882 mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593349] Modules linked in: act_ct nf_flow_table rdma_ucm(O) rdma_cm(O) iw_cm(O) ib_ipoib(O) ib_cm(O) ib_umad(O) mlx5_core(O-) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) psample ib_core(O) mlx_compat(O) ip_gre gre ip_tunnel act_vlan bonding geneve esp6_offload esp6 esp4_offload esp4 act_tunnel_key vxlan ip6_udp_tunnel udp_tunnel act_mirred act_skbedit act_gact cls_flower sch_ingress nfnetlink_cttimeout nfnetlink xfrm_user xfrm_algo 8021q garp stp ipmi_devintf mrp ipmi_msghandler llc openvswitch nsh nf_conncount nf_nat mst_pciconf(O) dm_multipath sbsa_gwdt uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio mlx_bootctl(O) bluefield_edac sch_fq_codel ip_tables ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 crct10dif_ce i2c_mlxbf gpio_mlxbf2 mlxbf_gige aes_neon_bs aes_neon_blk [last unloaded: mlx5_ib]<br /> [ 9443.593419] CPU: 2 PID: 206774 Comm: modprobe Tainted: G O 5.4.0-1023.24.gc14613d-bluefield #1<br /> [ 9443.593422] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:143ebaf Jan 11 2022<br /> [ 9443.593424] pstate: 20000005 (nzCv daif -PAN -UAO)<br /> [ 9443.593489] pc : mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593545] lr : mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]<br /> [ 9443.593546] sp : ffff8000135dbab0<br /> [ 9443.593548] x29: ffff8000135dbab0 x28: ffff0003a6ab8e80<br /> [ 9443.593550] x27: 0000000000000000 x26: ffff0003e07d7000<br /> [ 9443.593552] x25: ffff800009609de0 x24: ffff000397fb2120<br /> [ 9443.593554] x23: ffff0003975c0000 x22: 0000000000000000<br /> [ 9443.593556] x21: ffff0003975f08c0 x20: ffff800009609de0<br /> [ 9443.593558] x19: ffff0003c8a13380 x18: 0000000000000014<br /> [ 9443.593560] x17: 0000000067f5f125 x16: 000000006529c620<br /> [ 9443.593561] x15: 000000000000000b x14: 0000000000000000<br /> [ 9443.593563] x13: 0000000000000002 x12: 0000000000000001<br /> [ 9443.593565] x11: ffff800011108868 x10: 0000000000000000<br /> [ 9443.593567] x9 : 0000000000000000 x8 : ffff8000117fb270<br /> [ 9443.593569] x7 : ffff0003ebc01288 x6 : 0000000000000000<br /> [ 9443.593571] x5 : ffff800009591ab8 x4 : fffffe000f6d9a20<br /> [ 9443.593572] x3 : 0000000080040001 x2 : fffffe000f6d9a20<br /> [ 9443.593574] x1 : ffff8000095901d8 x0 : 0000000000000025<br /> [ 9443.593577] Call trace:<br /> [ 9443.593634] mlx5dr_action_destroy+0x188/0x1a0 [mlx5_core]<br /> [ 9443.593688] mlx5_ct_fs_smfs_destroy+0x24/0x30 [mlx5_core]<br /> [ 9443.593743] mlx5_tc_ct_clean+0x34/0xa8 [mlx5_core]<br /> [ 9443.593797] mlx5e_tc_esw_cleanup+0x58/0x88 [mlx5_core]<br /> [ 9443.593851] mlx5e_rep_tc_cleanup+0x24/0x30 [mlx5_core]<br /> [ 9443.593905] mlx5e_cleanup_rep_tx+0x6c/0x78 [mlx5_core]<br /> [ 9443.593959] mlx5e_detach_netdev+0x74/0x98 [mlx5_core]<br /> [ 9443.594013] mlx5e_netdev_change_profile+0x70/0x180 [mlx5_core]<br /> [ 9443.594067] mlx5e_netdev_attach_nic_profile+0x34/0x40 [mlx5_core]<br /> [ 9443.594122] mlx5e_vport_rep_unload+0x15c/0x1a8 [mlx5_core]<br /> [ 9443.594177] mlx5_eswitch_unregister_vport_reps+0x228/0x298 [mlx5_core]<br /> [ 9443.594231] mlx5e_rep_remove+0x2c/0x38<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: unexport __init-annotated seg6_hmac_init()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it has been broken for a decade.<br /> <br /> Recently, I fixed modpost so it started to warn it again, then this<br /> showed up in linux-next builds.<br /> <br /> There are two ways to fix it:<br /> <br /> - Remove __init<br /> - Remove EXPORT_SYMBOL<br /> <br /> I chose the latter for this case because the caller (net/ipv6/seg6.c)<br /> and the callee (net/ipv6/seg6_hmac.c) belong to the same module.<br /> It seems an internal function call in ipv6.ko.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip_gre: test csum_start instead of transport header<br /> <br /> GRE with TUNNEL_CSUM will apply local checksum offload on<br /> CHECKSUM_PARTIAL packets.<br /> <br /> ipgre_xmit must validate csum_start after an optional skb_pull,<br /> else lco_csum may trigger an overflow. The original check was<br /> <br /> if (csum &amp;&amp; skb_checksum_start(skb) data)<br /> return -EINVAL;<br /> <br /> This had false positives when skb_checksum_start is undefined:<br /> when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement<br /> was straightforward<br /> <br /> if (csum &amp;&amp; skb-&gt;ip_summed == CHECKSUM_PARTIAL &amp;&amp;<br /> skb_checksum_start(skb) data)<br /> return -EINVAL;<br /> <br /> But was eventually revised more thoroughly:<br /> - restrict the check to the only branch where needed, in an<br /> uncommon GRE path that uses header_ops and calls skb_pull.<br /> - test skb_transport_header, which is set along with csum_start<br /> in skb_partial_csum_set in the normal header_ops datapath.<br /> <br /> Turns out skbs can arrive in this branch without the transport<br /> header set, e.g., through BPF redirection.<br /> <br /> Revise the check back to check csum_start directly, and only if<br /> CHECKSUM_PARTIAL. Do leave the check in the updated location.<br /> Check field regardless of whether TUNNEL_CSUM is configured.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Clear prog-&gt;jited_len along prog-&gt;jited<br /> <br /> syzbot reported an illegal copy_to_user() attempt<br /> from bpf_prog_get_info_by_fd() [1]<br /> <br /> There was no repro yet on this bug, but I think<br /> that commit 0aef499f3172 ("mm/usercopy: Detect vmalloc overruns")<br /> is exposing a prior bug in bpf arm64.<br /> <br /> bpf_prog_get_info_by_fd() looks at prog-&gt;jited_len<br /> to determine if the JIT image can be copied out to user space.<br /> <br /> My theory is that syzbot managed to get a prog where prog-&gt;jited_len<br /> has been set to 43, while prog-&gt;bpf_func has ben cleared.<br /> <br /> It is not clear why copy_to_user(uinsns, NULL, ulen) is triggering<br /> this particular warning.<br /> <br /> I thought find_vma_area(NULL) would not find a vm_struct.<br /> As we do not hold vmap_area_lock spinlock, it might be possible<br /> that the found vm_struct was garbage.<br /> <br /> [1]<br /> usercopy: Kernel memory exposure attempt detected from vmalloc (offset 792633534417210172, size 43)!<br /> kernel BUG at mm/usercopy.c:101!<br /> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 25002 Comm: syz-executor.1 Not tainted 5.18.0-syzkaller-10139-g8291eaafed36 #0<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : usercopy_abort+0x90/0x94 mm/usercopy.c:101<br /> lr : usercopy_abort+0x90/0x94 mm/usercopy.c:89<br /> sp : ffff80000b773a20<br /> x29: ffff80000b773a30 x28: faff80000b745000 x27: ffff80000b773b48<br /> x26: 0000000000000000 x25: 000000000000002b x24: 0000000000000000<br /> x23: 00000000000000e0 x22: ffff80000b75db67 x21: 0000000000000001<br /> x20: 000000000000002b x19: ffff80000b75db3c x18: 00000000fffffffd<br /> x17: 2820636f6c6c616d x16: 76206d6f72662064 x15: 6574636574656420<br /> x14: 74706d6574746120 x13: 2129333420657a69 x12: 73202c3237313031<br /> x11: 3237313434333533 x10: 3336323937207465 x9 : 657275736f707865<br /> x8 : ffff80000a30c550 x7 : ffff80000b773830 x6 : ffff80000b773830<br /> x5 : 0000000000000000 x4 : ffff00007fbbaa10 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : f7ff000028fc0000 x0 : 0000000000000064<br /> Call trace:<br /> usercopy_abort+0x90/0x94 mm/usercopy.c:89<br /> check_heap_object mm/usercopy.c:186 [inline]<br /> __check_object_size mm/usercopy.c:252 [inline]<br /> __check_object_size+0x198/0x36c mm/usercopy.c:214<br /> check_object_size include/linux/thread_info.h:199 [inline]<br /> check_copy_size include/linux/thread_info.h:235 [inline]<br /> copy_to_user include/linux/uaccess.h:159 [inline]<br /> bpf_prog_get_info_by_fd.isra.0+0xf14/0xfdc kernel/bpf/syscall.c:3993<br /> bpf_obj_get_info_by_fd+0x12c/0x510 kernel/bpf/syscall.c:4253<br /> __sys_bpf+0x900/0x2150 kernel/bpf/syscall.c:4956<br /> __do_sys_bpf kernel/bpf/syscall.c:5021 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5019 [inline]<br /> __arm64_sys_bpf+0x28/0x40 kernel/bpf/syscall.c:5019<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52<br /> el0_svc_common.constprop.0+0x44/0xec arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0xa0/0xc0 arch/arm64/kernel/syscall.c:206<br /> el0_svc+0x44/0xb0 arch/arm64/kernel/entry-common.c:624<br /> el0t_64_sync_handler+0x1ac/0x1b0 arch/arm64/kernel/entry-common.c:642<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:581<br /> Code: aa0003e3 d00038c0 91248000 97fff65f (d4210000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix sleeping function called from invalid context on RT kernel<br /> <br /> When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the<br /> cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the<br /> atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel,<br /> these locks are replaced with sleepable rt-spinlock, so the stack calltrace will<br /> be triggered.<br /> Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start<br /> tp_printk=1" enabled.<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0<br /> preempt_count: 2, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> Preemption disabled at:<br /> [] try_to_wake_up+0x7e/0xba0<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x60/0x8c<br /> dump_stack+0x10/0x12<br /> __might_resched.cold+0x11d/0x155<br /> rt_spin_lock+0x40/0x70<br /> trace_event_buffer_commit+0x2fa/0x4c0<br /> ? map_vsyscall+0x93/0x93<br /> trace_event_raw_event_initcall_start+0xbe/0x110<br /> ? perf_trace_initcall_finish+0x210/0x210<br /> ? probe_sched_wakeup+0x34/0x40<br /> ? ttwu_do_wakeup+0xda/0x310<br /> ? trace_hardirqs_on+0x35/0x170<br /> ? map_vsyscall+0x93/0x93<br /> do_one_initcall+0x217/0x3c0<br /> ? trace_event_raw_event_initcall_level+0x170/0x170<br /> ? push_cpu_stop+0x400/0x400<br /> ? cblist_init_generic+0x241/0x290<br /> kernel_init_freeable+0x1ac/0x347<br /> ? _raw_spin_unlock_irq+0x65/0x80<br /> ? rest_init+0xf0/0xf0<br /> kernel_init+0x1e/0x150<br /> ret_from_fork+0x22/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: cpc: Fix refcount leak in mips_cpc_default_phys_base<br /> <br /> Add the missing of_node_put() to release the refcount incremented<br /> by of_find_compatible_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: add accessors to read/set tp-&gt;snd_cwnd<br /> <br /> We had various bugs over the years with code<br /> breaking the assumption that tp-&gt;snd_cwnd is greater<br /> than zero.<br /> <br /> Lately, syzbot reported the WARN_ON_ONCE(!tp-&gt;prior_cwnd) added<br /> in commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")<br /> can trigger, and without a repro we would have to spend<br /> considerable time finding the bug.<br /> <br /> Instead of complaining too late, we want to catch where<br /> and when tp-&gt;snd_cwnd is set to an illegal value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtl818x: Prevent using not initialized queues<br /> <br /> Using not existing queues can panic the kernel with rtl8180/rtl8185 cards.<br /> Ignore the skb priority for those cards, they only have one tx queue. Pierre<br /> Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum:<br /> <br /> https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html<br /> <br /> He also confirmed that this patch fixes the issue. In summary this happened:<br /> <br /> After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a<br /> "divide error: 0000" when connecting to an AP. Control port tx now tries to<br /> use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in<br /> 2.10.<br /> <br /> Since only the rtl8187se part of the driver supports QoS, the priority<br /> of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185<br /> cards.<br /> <br /> rtl8180 is then unconditionally reading out the priority and finally crashes on<br /> drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this<br /> patch:<br /> idx = (ring-&gt;idx + skb_queue_len(&amp;ring-&gt;queue)) % ring-&gt;entries<br /> <br /> "ring-&gt;entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: avoid journal no-space deadlock by reserving 1 journal bucket<br /> <br /> The journal no-space deadlock was reported time to time. Such deadlock<br /> can happen in the following situation.<br /> <br /> When all journal buckets are fully filled by active jset with heavy<br /> write I/O load, the cache set registration (after a reboot) will load<br /> all active jsets and inserting them into the btree again (which is<br /> called journal replay). If a journaled bkey is inserted into a btree<br /> node and results btree node split, new journal request might be<br /> triggered. For example, the btree grows one more level after the node<br /> split, then the root node record in cache device super block will be<br /> upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no<br /> space in journal buckets, the journal replay has to wait for new journal<br /> bucket to be reclaimed after at least one journal bucket replayed. This<br /> is one example that how the journal no-space deadlock happens.<br /> <br /> The solution to avoid the deadlock is to reserve 1 journal bucket in<br /> run time, and only permit the reserved journal bucket to be used during<br /> cache set registration procedure for things like journal replay. Then<br /> the journal space will never be fully filled, there is no chance for<br /> journal no-space deadlock to happen anymore.<br /> <br /> This patch adds a new member "bool do_reserve" in struct journal, it is<br /> inititalized to 0 (false) when struct journal is allocated, and set to<br /> 1 (true) by bch_journal_space_reserve() when all initialization done in<br /> run_cache_set(). In the run time when journal_reclaim() tries to<br /> allocate a new journal bucket, free_journal_buckets() is called to check<br /> whether there are enough free journal buckets to use. If there is only<br /> 1 free journal bucket and journal-&gt;do_reserve is 1 (true), the last<br /> bucket is reserved and free_journal_buckets() will return 0 to indicate<br /> no free journal bucket. Then journal_reclaim() will give up, and try<br /> next time to see whetheer there is free journal bucket to allocate. By<br /> this method, there is always 1 jouranl bucket reserved in run time.<br /> <br /> During the cache set registration, journal-&gt;do_reserve is 0 (false), so<br /> the reserved journal bucket can be used to avoid the no-space deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: fix use-after-free by removing a non-RCU wcid pointer<br /> <br /> Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule<br /> by protecting mtxq-&gt;wcid with rcu_lock between mt76_txq_schedule and<br /> sta_info_[alloc, free].<br /> <br /> [18853.876689] ==================================================================<br /> [18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76]<br /> [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883<br /> [18853.876786]<br /> [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215<br /> <br /> [18853.876840] Call trace:<br /> [18853.876861] dump_backtrace+0x0/0x3ec<br /> [18853.876878] show_stack+0x20/0x2c<br /> [18853.876899] dump_stack+0x11c/0x1ac<br /> [18853.876918] print_address_description+0x74/0x514<br /> [18853.876934] kasan_report+0x134/0x174<br /> [18853.876948] __asan_report_load8_noabort+0x44/0x50<br /> [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047]<br /> [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2]<br /> [18853.877071] kthread+0x2f8/0x3b8<br /> [18853.877087] ret_from_fork+0x10/0x30<br /> [18853.877098]<br /> [18853.877112] Allocated by task 941:<br /> [18853.877131] kasan_save_stack+0x38/0x68<br /> [18853.877147] __kasan_kmalloc+0xd4/0xfc<br /> [18853.877163] kasan_kmalloc+0x10/0x1c<br /> [18853.877177] __kmalloc+0x264/0x3c4<br /> [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211]<br /> [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211]<br /> [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211]<br /> [18853.877635] ieee80211_auth+0x20/0x2c [mac80211]<br /> [18853.877733] rdev_auth+0x7c/0x438 [cfg80211]<br /> [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211]<br /> [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211]<br /> [18853.877938] genl_rcv_msg+0x748/0x93c<br /> [18853.877954] netlink_rcv_skb+0x160/0x2a8<br /> [18853.877969] genl_rcv+0x3c/0x54<br /> [18853.877985] netlink_unicast_kernel+0x104/0x1ec<br /> [18853.877999] netlink_unicast+0x178/0x268<br /> [18853.878015] netlink_sendmsg+0x3cc/0x5f0<br /> [18853.878030] sock_sendmsg+0xb4/0xd8<br /> [18853.878043] ____sys_sendmsg+0x2f8/0x53c<br /> [18853.878058] ___sys_sendmsg+0xe8/0x150<br /> [18853.878071] __sys_sendmsg+0xc4/0x1f4<br /> [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c<br /> [18853.878101] el0_svc_common+0x1b4/0x390<br /> [18853.878115] do_el0_svc_compat+0x8c/0xdc<br /> [18853.878131] el0_svc_compat+0x10/0x1c<br /> [18853.878146] el0_sync_compat_handler+0xa8/0xcc<br /> [18853.878161] el0_sync_compat+0x188/0x1c0<br /> [18853.878171]<br /> [18853.878183] Freed by task 10927:<br /> [18853.878200] kasan_save_stack+0x38/0x68<br /> [18853.878215] kasan_set_track+0x28/0x3c<br /> [18853.878228] kasan_set_free_info+0x24/0x48<br /> [18853.878244] __kasan_slab_free+0x11c/0x154<br /> [18853.878259] kasan_slab_free+0x14/0x24<br /> [18853.878273] slab_free_freelist_hook+0xac/0x1b0<br /> [18853.878287] kfree+0x104/0x390<br /> [18853.878402] sta_info_free+0x198/0x210 [mac80211]<br /> [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211]<br /> [18853.878628] __sta_info_flush+0x300/0x37c [mac80211]<br /> [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211]<br /> [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211]<br /> [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211]<br /> [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211]<br /> [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211]<br /> [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211]<br /> [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211]<br /> [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211]<br /> [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211]<br /> [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211]<br /> [18853.879628] dpm_run_callback+0x58/0x408<br /> [18853.879642] __device_suspend+0x4cc/0x864<br /> [18853.879658] async_suspend+0x34/0xf4<br /> [18<br /> ---truncated---