Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: fix possible cp null dereference<br /> <br /> cp might be null, calling cp-&gt;cp_conn would produce null dereference<br /> <br /> [Simon Horman adds:]<br /> <br /> Analysis:<br /> <br /> * cp is a parameter of __rds_rdma_map and is not reassigned.<br /> <br /> * The following call-sites pass a NULL cp argument to __rds_rdma_map()<br /> <br /> - rds_get_mr()<br /> - rds_get_mr_for_dest<br /> <br /> * Prior to the code above, the following assumes that cp may be NULL<br /> (which is indicative, but could itself be unnecessary)<br /> <br /> trans_private = rs-&gt;rs_transport-&gt;get_mr(<br /> sg, nents, rs, &amp;mr-&gt;r_key, cp ? cp-&gt;cp_conn : NULL,<br /> args-&gt;vec.addr, args-&gt;vec.bytes,<br /> need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);<br /> <br /> * The code modified by this patch is guarded by IS_ERR(trans_private),<br /> where trans_private is assigned as per the previous point in this analysis.<br /> <br /> The only implementation of get_mr that I could locate is rds_ib_get_mr()<br /> which can return an ERR_PTR if the conn (4th) argument is NULL.<br /> <br /> * ret is set to PTR_ERR(trans_private).<br /> rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.<br /> Thus ret may be -ENODEV in which case the code in question will execute.<br /> <br /> Conclusion:<br /> * cp may be NULL at the point where this patch adds a check;<br /> this patch does seem to address a possible bug

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/bpf: Fix IP after emitting call depth accounting<br /> <br /> Adjust the IP passed to `emit_patch` so it calculates the correct offset<br /> for the CALL instruction if `x86_call_depth_emit_accounting` emits code.<br /> Otherwise we will skip some instructions and most likely crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: avoid dereference of garbage after mount failure<br /> <br /> In case kern_mount() fails and returns an error pointer return in the<br /> error branch instead of continuing and dereferencing the error pointer.<br /> <br /> While on it drop the never read static variable selinuxfs_mount.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Protect against int overflow for stack access size<br /> <br /> This patch re-introduces protection against the size of access to stack<br /> memory being negative; the access size can appear negative as a result<br /> of overflowing its signed int representation. This should not actually<br /> happen, as there are other protections along the way, but we should<br /> protect against it anyway. One code path was missing such protections<br /> (fixed in the previous patch in the series), causing out-of-bounds array<br /> accesses in check_stack_range_initialized(). This patch causes the<br /> verification of a program with such a non-sensical access size to fail.<br /> <br /> This check used to exist in a more indirect way, but was inadvertendly<br /> removed in a833a17aeac7.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Send DTBCLK disable message on first commit<br /> <br /> [Why]<br /> Previous patch to allow DTBCLK disable didn&amp;#39;t address boot case. Driver<br /> thinks DTBCLK is disabled by default, so we don&amp;#39;t send disable message to<br /> PMFW. DTBCLK is then enabled at idle desktop on boot, burning power.<br /> <br /> [How]<br /> Set dtbclk_en to true on boot so that disable message is sent during first<br /> commit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxbf_gige: call request_irq() after NAPI initialized<br /> <br /> The mlxbf_gige driver encounters a NULL pointer exception in<br /> mlxbf_gige_open() when kdump is enabled. The sequence to reproduce<br /> the exception is as follows:<br /> a) enable kdump<br /> b) trigger kdump via "echo c &gt; /proc/sysrq-trigger"<br /> c) kdump kernel executes<br /> d) kdump kernel loads mlxbf_gige module<br /> e) the mlxbf_gige module runs its open() as the<br /> the "oob_net0" interface is brought up<br /> f) mlxbf_gige module will experience an exception<br /> during its open(), something like:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Mem abort info:<br /> ESR = 0x0000000086000004<br /> EC = 0x21: IABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000<br /> [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000086000004 [#1] SMP<br /> CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu<br /> Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : 0x0<br /> lr : __napi_poll+0x40/0x230<br /> sp : ffff800008003e00<br /> x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff<br /> x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8<br /> x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000<br /> x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000<br /> x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0<br /> x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398<br /> x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2<br /> x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238<br /> Call trace:<br /> 0x0<br /> net_rx_action+0x178/0x360<br /> __do_softirq+0x15c/0x428<br /> __irq_exit_rcu+0xac/0xec<br /> irq_exit+0x18/0x2c<br /> handle_domain_irq+0x6c/0xa0<br /> gic_handle_irq+0xec/0x1b0<br /> call_on_irq_stack+0x20/0x2c<br /> do_interrupt_handler+0x5c/0x70<br /> el1_interrupt+0x30/0x50<br /> el1h_64_irq_handler+0x18/0x2c<br /> el1h_64_irq+0x7c/0x80<br /> __setup_irq+0x4c0/0x950<br /> request_threaded_irq+0xf4/0x1bc<br /> mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]<br /> mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]<br /> __dev_open+0x100/0x220<br /> __dev_change_flags+0x16c/0x1f0<br /> dev_change_flags+0x2c/0x70<br /> do_setlink+0x220/0xa40<br /> __rtnl_newlink+0x56c/0x8a0<br /> rtnl_newlink+0x58/0x84<br /> rtnetlink_rcv_msg+0x138/0x3c4<br /> netlink_rcv_skb+0x64/0x130<br /> rtnetlink_rcv+0x20/0x30<br /> netlink_unicast+0x2ec/0x360<br /> netlink_sendmsg+0x278/0x490<br /> __sock_sendmsg+0x5c/0x6c<br /> ____sys_sendmsg+0x290/0x2d4<br /> ___sys_sendmsg+0x84/0xd0<br /> __sys_sendmsg+0x70/0xd0<br /> __arm64_sys_sendmsg+0x2c/0x40<br /> invoke_syscall+0x78/0x100<br /> el0_svc_common.constprop.0+0x54/0x184<br /> do_el0_svc+0x30/0xac<br /> el0_svc+0x48/0x160<br /> el0t_64_sync_handler+0xa4/0x12c<br /> el0t_64_sync+0x1a4/0x1a8<br /> Code: bad PC value<br /> ---[ end trace 7d1c3f3bf9d81885 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt<br /> Kernel Offset: 0x2870a7a00000 from 0xffff800008000000<br /> PHYS_OFFSET: 0x80000000<br /> CPU features: 0x0,000005c1,a3332a5a<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---<br /> <br /> The exception happens because there is a pending RX interrupt before the<br /> call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires<br /> immediately after this request_irq() completes. The<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: get psock ref after taking rxlock to avoid leak<br /> <br /> At the start of tls_sw_recvmsg, we take a reference on the psock, and<br /> then call tls_rx_reader_lock. If that fails, we return directly<br /> without releasing the reference.<br /> <br /> Instead of adding a new label, just take the reference after locking<br /> has succeeded, since we don&amp;#39;t need it before.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: t7xx: Split 64bit accesses to fix alignment issues<br /> <br /> Some of the registers are aligned on a 32bit boundary, causing<br /> alignment faults on 64bit platforms.<br /> <br /> Unable to handle kernel paging request at virtual address ffffffc084a1d004<br /> Mem abort info:<br /> ESR = 0x0000000096000061<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x21: alignment fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000061, ISS2 = 0x00000000<br /> CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000046ad6000<br /> [ffffffc084a1d004] pgd=100000013ffff003, p4d=100000013ffff003, pud=100000013ffff003, pmd=0068000020a00711<br /> Internal error: Oops: 0000000096000061 [#1] SMP<br /> Modules linked in: mtk_t7xx(+) qcserial pppoe ppp_async option nft_fib_inet nf_flow_table_inet mt7921u(O) mt7921s(O) mt7921e(O) mt7921_common(O) iwlmvm(O) iwldvm(O) usb_wwan rndis_host qmi_wwan pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7996e(O) mt792x_usb(O) mt792x_lib(O) mt7915e(O) mt76_usb(O) mt76_sdio(O) mt76_connac_lib(O) mt76(O) mac80211(O) iwlwifi(O) huawei_cdc_ncm cfg80211(O) cdc_ncm cdc_ether wwan usbserial usbnet slhc sfp rtc_pcf8563 nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mt6577_auxadc mdio_i2c libcrc32c compat(O) cdc_wdm cdc_acm at24 crypto_safexcel pwm_fan i2c_gpio i2c_smbus industrialio i2c_algo_bit i2c_mux_reg i2c_mux_pca954x i2c_mux_pca9541 i2c_mux_gpio i2c_mux dummy oid_registry tun sha512_arm64 sha1_ce sha1_generic seqiv<br /> md5 geniv des_generic libdes cbc authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd nvme nvme_core gpio_button_hotplug(O) dm_mirror dm_region_hash dm_log dm_crypt dm_mod dax usbcore usb_common ptp aquantia pps_core mii tpm encrypted_keys trusted<br /> CPU: 3 PID: 5266 Comm: kworker/u9:1 Tainted: G O 6.6.22 #0<br /> Hardware name: Bananapi BPI-R4 (DT)<br /> Workqueue: md_hk_wq t7xx_fsm_uninit [mtk_t7xx]<br /> pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx]<br /> lr : t7xx_cldma_start+0xac/0x13c [mtk_t7xx]<br /> sp : ffffffc085d63d30<br /> x29: ffffffc085d63d30 x28: 0000000000000000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffffff80c804f2c0 x24: ffffff80ca196c05<br /> x23: 0000000000000000 x22: ffffff80c814b9b8 x21: ffffff80c814b128<br /> x20: 0000000000000001 x19: ffffff80c814b080 x18: 0000000000000014<br /> x17: 0000000055c9806b x16: 000000007c5296d0 x15: 000000000f6bca68<br /> x14: 00000000dbdbdce4 x13: 000000001aeaf72a x12: 0000000000000001<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : ffffff80ca1ef6b4 x7 : ffffff80c814b818 x6 : 0000000000000018<br /> x5 : 0000000000000870 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 000000010a947000 x1 : ffffffc084a1d004 x0 : ffffffc084a1d004<br /> Call trace:<br /> t7xx_cldma_hw_set_start_addr+0x1c/0x3c [mtk_t7xx]<br /> t7xx_fsm_uninit+0x578/0x5ec [mtk_t7xx]<br /> process_one_work+0x154/0x2a0<br /> worker_thread+0x2ac/0x488<br /> kthread+0xe0/0xec<br /> ret_from_fork+0x10/0x20<br /> Code: f9400800 91001000 8b214001 d50332bf (f9000022)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The inclusion of io-64-nonatomic-lo-hi.h indicates that all 64bit<br /> accesses can be replaced by pairs of nonatomic 32bit access. Fix<br /> alignment by forcing all accesses to be 32bit on 64bit platforms.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: properly terminate timers for kernel sockets<br /> <br /> We had various syzbot reports about tcp timers firing after<br /> the corresponding netns has been dismantled.<br /> <br /> Fortunately Josef Bacik could trigger the issue more often,<br /> and could test a patch I wrote two years ago.<br /> <br /> When TCP sockets are closed, we call inet_csk_clear_xmit_timers()<br /> to &amp;#39;stop&amp;#39; the timers.<br /> <br /> inet_csk_clear_xmit_timers() can be called from any context,<br /> including when socket lock is held.<br /> This is the reason it uses sk_stop_timer(), aka del_timer().<br /> This means that ongoing timers might finish much later.<br /> <br /> For user sockets, this is fine because each running timer<br /> holds a reference on the socket, and the user socket holds<br /> a reference on the netns.<br /> <br /> For kernel sockets, we risk that the netns is freed before<br /> timer can complete, because kernel sockets do not hold<br /> reference on the netns.<br /> <br /> This patch adds inet_csk_clear_xmit_timers_sync() function<br /> that using sk_stop_timer_sync() to make sure all timers<br /> are terminated before the kernel socket is released.<br /> Modules using kernel sockets close them in their netns exit()<br /> handler.<br /> <br /> Also add sock_not_owned_by_me() helper to get LOCKDEP<br /> support : inet_csk_clear_xmit_timers_sync() must not be called<br /> while socket lock is held.<br /> <br /> It is very possible we can revert in the future commit<br /> 3a58f13a881e ("net: rds: acquire refcount on TCP sockets")<br /> which attempted to solve the issue in rds only.<br /> (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)<br /> <br /> We probably can remove the check_net() tests from<br /> tcp_out_of_resources() and __tcp_close() in the future.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix memory corruption bug with suspend and rebuild<br /> <br /> The ice driver would previously panic after suspend. This is caused<br /> from the driver *only* calling the ice_vsi_free_q_vectors() function by<br /> itself, when it is suspending. Since commit b3e7b3a6ee92 ("ice: prevent<br /> NULL pointer deref during reload") the driver has zeroed out<br /> num_q_vectors, and only restored it in ice_vsi_cfg_def().<br /> <br /> This further causes the ice_rebuild() function to allocate a zero length<br /> buffer, after which num_q_vectors is updated, and then the new value of<br /> num_q_vectors is used to index into the zero length buffer, which<br /> corrupts memory.<br /> <br /> The fix entails making sure all the code referencing num_q_vectors only<br /> does so after it has been reset via ice_vsi_cfg_def().<br /> <br /> I didn&amp;#39;t perform a full bisect, but I was able to test against 6.1.77<br /> kernel and that ice driver works fine for suspend/resume with no panic,<br /> so sometime since then, this problem was introduced.<br /> <br /> Also clean up an un-needed init of a local variable in the function<br /> being modified.<br /> <br /> PANIC from 6.8.0-rc1:<br /> <br /> [1026674.915596] PM: suspend exit<br /> [1026675.664697] ice 0000:17:00.1: PTP reset successful<br /> [1026675.664707] ice 0000:17:00.1: 2755 msecs passed between update to cached PHC time<br /> [1026675.667660] ice 0000:b1:00.0: PTP reset successful<br /> [1026675.675944] ice 0000:b1:00.0: 2832 msecs passed between update to cached PHC time<br /> [1026677.137733] ixgbe 0000:31:00.0 ens787: NIC Link is Up 1 Gbps, Flow Control: None<br /> [1026677.190201] BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> [1026677.192753] ice 0000:17:00.0: PTP reset successful<br /> [1026677.192764] ice 0000:17:00.0: 4548 msecs passed between update to cached PHC time<br /> [1026677.197928] #PF: supervisor read access in kernel mode<br /> [1026677.197933] #PF: error_code(0x0000) - not-present page<br /> [1026677.197937] PGD 1557a7067 P4D 0<br /> [1026677.212133] ice 0000:b1:00.1: PTP reset successful<br /> [1026677.212143] ice 0000:b1:00.1: 4344 msecs passed between update to cached PHC time<br /> [1026677.212575]<br /> [1026677.243142] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: loaded Tainted: G W 6.8.0-rc1+ #1<br /> [1026677.257989] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022<br /> [1026677.269367] Workqueue: ice ice_service_task [ice]<br /> [1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]<br /> [1026677.281421] Code: 0f 84 3a ff ff ff 41 0f b7 74 ec 02 66 89 b0 22 02 00 00 81 e6 ff 1f 00 00 e8 ec fd ff ff e9 35 ff ff ff 48 8b 43 30 49 63 ed 0f b7 34 24 41 83 c5 01 48 8b 3c e8 66 89 b7 aa 02 00 00 81 e6<br /> [1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 00010202<br /> [1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000<br /> [1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828<br /> [1026677.321730] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> [1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010<br /> [1026677.336896] R13: 0000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0<br /> [1026677.344472] FS: 0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000<br /> [1026677.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0<br /> [1026677.366779] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [1026677.381952] PKRU: 55555554<br /> [1026677.385116] Call Trace:<br /> [1026677.388023] <br /> [1026677.390589] ? __die+0x20/0x70<br /> [1026677.394105] ? page_fault_oops+0x82/0x160<br /> [1026677.398576] ? do_user_addr_fault+0x65/0x6a0<br /> [1026677.403307] ? exc_page_fault+0x6a/0x150<br /> [1026677.407694] ? asm_exc_page_fault+0x22/0x30<br /> [1026677.412349] ? ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]<br /> [1026677.4186<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: rfi: fix potential response leaks<br /> <br /> If the rx payload length check fails, or if kmemdup() fails,<br /> we still need to free the command response. Fix that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: pick the version of SESSION_PROTECTION_NOTIF<br /> <br /> When we want to know whether we should look for the mac_id or the<br /> link_id in struct iwl_mvm_session_prot_notif, we should look at the<br /> version of SESSION_PROTECTION_NOTIF.<br /> <br /> This causes WARNINGs:<br /> <br /> WARNING: CPU: 0 PID: 11403 at drivers/net/wireless/intel/iwlwifi/mvm/time-event.c:959 iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]<br /> RIP: 0010:iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]<br /> Code: 00 49 c7 84 24 48 07 00 00 00 00 00 00 41 c6 84 24 78 07 00 00 ff 4c 89 f7 e8 e9 71 54 d9 e9 7d fd ff ff 0f 0b e9 23 fe ff ff 0b e9 1c fe ff ff 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90<br /> RSP: 0018:ffffb4bb00003d40 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff9ae63a361000 RCX: ffff9ae4a98b60d4<br /> RDX: ffff9ae4588499c0 RSI: 0000000000000305 RDI: ffff9ae4a98b6358<br /> RBP: ffffb4bb00003d68 R08: 0000000000000003 R09: 0000000000000010<br /> R10: ffffb4bb00003d00 R11: 000000000000000f R12: ffff9ae441399050<br /> R13: ffff9ae4761329e8 R14: 0000000000000001 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff9ae7af400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055fb75680018 CR3: 00000003dae32006 CR4: 0000000000f70ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_regs+0x69/0x80<br /> ? __warn+0x8d/0x150<br /> ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]<br /> ? report_bug+0x196/0x1c0<br /> ? handle_bug+0x45/0x80<br /> ? exc_invalid_op+0x1c/0xb0<br /> ? asm_exc_invalid_op+0x1f/0x30<br /> ? iwl_mvm_rx_session_protect_notif+0x333/0x340 [iwlmvm]<br /> iwl_mvm_rx_common+0x115/0x340 [iwlmvm]<br /> iwl_mvm_rx_mq+0xa6/0x100 [iwlmvm]<br /> iwl_pcie_rx_handle+0x263/0xa10 [iwlwifi]<br /> iwl_pcie_napi_poll_msix+0x32/0xd0 [iwlwifi]