Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: Delay the unmapping of the buffer<br /> <br /> On WCN3990, we are seeing a rare scenario where copy engine hardware is<br /> sending a copy complete interrupt to the host driver while still<br /> processing the buffer that the driver has sent, this is leading into an<br /> SMMU fault triggering kernel panic. This is happening on copy engine<br /> channel 3 (CE3) where the driver normally enqueues WMI commands to the<br /> firmware. Upon receiving a copy complete interrupt, host driver will<br /> immediately unmap and frees the buffer presuming that hardware has<br /> processed the buffer. In the issue case, upon receiving copy complete<br /> interrupt, host driver will unmap and free the buffer but since hardware<br /> is still accessing the buffer (which in this case got unmapped in<br /> parallel), SMMU hardware will trigger an SMMU fault resulting in a<br /> kernel panic.<br /> <br /> In order to avoid this, as a work around, add a delay before unmapping<br /> the copy engine source DMA buffer. This is conditionally done for<br /> WCN3990 and only for the CE3 channel where issue is seen.<br /> <br /> Below is the crash signature:<br /> <br /> wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandled<br /> context fault: fsr=0x402, iova=0x7fdfd8ac0,<br /> fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled<br /> context fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,<br /> cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error<br /> received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:<br /> cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149<br /> remoteproc remoteproc0: crash detected in<br /> 4080000.remoteproc: type fatal error remoteproc remoteproc0:<br /> handling crash #1 in 4080000.remoteproc<br /> <br /> pc : __arm_lpae_unmap+0x500/0x514<br /> lr : __arm_lpae_unmap+0x4bc/0x514<br /> sp : ffffffc011ffb530<br /> x29: ffffffc011ffb590 x28: 0000000000000000<br /> x27: 0000000000000000 x26: 0000000000000004<br /> x25: 0000000000000003 x24: ffffffc011ffb890<br /> x23: ffffffa762ef9be0 x22: ffffffa77244ef00<br /> x21: 0000000000000009 x20: 00000007fff7c000<br /> x19: 0000000000000003 x18: 0000000000000000<br /> x17: 0000000000000004 x16: ffffffd7a357d9f0<br /> x15: 0000000000000000 x14: 00fd5d4fa7ffffff<br /> x13: 000000000000000e x12: 0000000000000000<br /> x11: 00000000ffffffff x10: 00000000fffffe00<br /> x9 : 000000000000017c x8 : 000000000000000c<br /> x7 : 0000000000000000 x6 : ffffffa762ef9000<br /> x5 : 0000000000000003 x4 : 0000000000000004<br /> x3 : 0000000000001000 x2 : 00000007fff7c000<br /> x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:<br /> __arm_lpae_unmap+0x500/0x514<br /> __arm_lpae_unmap+0x4bc/0x514<br /> __arm_lpae_unmap+0x4bc/0x514<br /> arm_lpae_unmap_pages+0x78/0xa4<br /> arm_smmu_unmap_pages+0x78/0x104<br /> __iommu_unmap+0xc8/0x1e4<br /> iommu_unmap_fast+0x38/0x48<br /> __iommu_dma_unmap+0x84/0x104<br /> iommu_dma_free+0x34/0x50<br /> dma_free_attrs+0xa4/0xd0<br /> ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c<br /> [ath10k_core]<br /> ath10k_halt+0x11c/0x180 [ath10k_core]<br /> ath10k_stop+0x54/0x94 [ath10k_core]<br /> drv_stop+0x48/0x1c8 [mac80211]<br /> ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c<br /> [mac80211]<br /> __dev_open+0xb4/0x174<br /> __dev_change_flags+0xc4/0x1dc<br /> dev_change_flags+0x3c/0x7c<br /> devinet_ioctl+0x2b4/0x580<br /> inet_ioctl+0xb0/0x1b4<br /> sock_do_ioctl+0x4c/0x16c<br /> compat_ifreq_ioctl+0x1cc/0x35c<br /> compat_sock_ioctl+0x110/0x2ac<br /> __arm64_compat_sys_ioctl+0xf4/0x3e0<br /> el0_svc_common+0xb4/0x17c<br /> el0_svc_compat_handler+0x2c/0x58<br /> el0_svc_compat+0x8/0x2c<br /> <br /> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921s: fix slab-out-of-bounds access in sdio host<br /> <br /> SDIO may need addtional 511 bytes to align bus operation. If the tailroom<br /> of this skb is not big enough, we would access invalid memory region.<br /> For low level operation, increase skb size to keep valid memory access in<br /> SDIO host.<br /> <br /> Error message:<br /> [69.951] BUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0xe9/0x1a0<br /> [69.951] Read of size 64 at addr ffff88811c9cf000 by task kworker/u16:7/451<br /> [69.951] CPU: 4 PID: 451 Comm: kworker/u16:7 Tainted: G W OE 6.1.0-rc5 #1<br /> [69.951] Workqueue: kvub300c vub300_cmndwork_thread [vub300]<br /> [69.951] Call Trace:<br /> [69.951] <br /> [69.952] dump_stack_lvl+0x49/0x63<br /> [69.952] print_report+0x171/0x4a8<br /> [69.952] kasan_report+0xb4/0x130<br /> [69.952] kasan_check_range+0x149/0x1e0<br /> [69.952] memcpy+0x24/0x70<br /> [69.952] sg_copy_buffer+0xe9/0x1a0<br /> [69.952] sg_copy_to_buffer+0x12/0x20<br /> [69.952] __command_write_data.isra.0+0x23c/0xbf0 [vub300]<br /> [69.952] vub300_cmndwork_thread+0x17f3/0x58b0 [vub300]<br /> [69.952] process_one_work+0x7ee/0x1320<br /> [69.952] worker_thread+0x53c/0x1240<br /> [69.952] kthread+0x2b8/0x370<br /> [69.952] ret_from_fork+0x1f/0x30<br /> [69.952] <br /> <br /> [69.952] Allocated by task 854:<br /> [69.952] kasan_save_stack+0x26/0x50<br /> [69.952] kasan_set_track+0x25/0x30<br /> [69.952] kasan_save_alloc_info+0x1b/0x30<br /> [69.952] __kasan_kmalloc+0x87/0xa0<br /> [69.952] __kmalloc_node_track_caller+0x63/0x150<br /> [69.952] kmalloc_reserve+0x31/0xd0<br /> [69.952] __alloc_skb+0xfc/0x2b0<br /> [69.952] __mt76_mcu_msg_alloc+0xbf/0x230 [mt76]<br /> [69.952] mt76_mcu_send_and_get_msg+0xab/0x110 [mt76]<br /> [69.952] __mt76_mcu_send_firmware.cold+0x94/0x15d [mt76]<br /> [69.952] mt76_connac_mcu_send_ram_firmware+0x415/0x54d [mt76_connac_lib]<br /> [69.952] mt76_connac2_load_ram.cold+0x118/0x4bc [mt76_connac_lib]<br /> [69.952] mt7921_run_firmware.cold+0x2e9/0x405 [mt7921_common]<br /> [69.952] mt7921s_mcu_init+0x45/0x80 [mt7921s]<br /> [69.953] mt7921_init_work+0xe1/0x2a0 [mt7921_common]<br /> [69.953] process_one_work+0x7ee/0x1320<br /> [69.953] worker_thread+0x53c/0x1240<br /> [69.953] kthread+0x2b8/0x370<br /> [69.953] ret_from_fork+0x1f/0x30<br /> [69.953] The buggy address belongs to the object at ffff88811c9ce800<br /> which belongs to the cache kmalloc-2k of size 2048<br /> [69.953] The buggy address is located 0 bytes to the right of<br /> 2048-byte region [ffff88811c9ce800, ffff88811c9cf000)<br /> <br /> [69.953] Memory state around the buggy address:<br /> [69.953] ffff88811c9cef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [69.953] ffff88811c9cef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> [69.953] &gt;ffff88811c9cf000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [69.953] ^<br /> [69.953] ffff88811c9cf080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> [69.953] ffff88811c9cf100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init()<br /> <br /> Inject fault while probing module, if device_register() fails in<br /> vdpasim_net_init() or vdpasim_blk_init(), but the refcount of kobject is<br /> not decreased to 0, the name allocated in dev_set_name() is leaked.<br /> Fix this by calling put_device(), so that name can be freed in<br /> callback function kobject_cleanup().<br /> <br /> (vdpa_sim_net)<br /> unreferenced object 0xffff88807eebc370 (size 16):<br /> comm "modprobe", pid 3848, jiffies 4362982860 (age 18.153s)<br /> hex dump (first 16 bytes):<br /> 76 64 70 61 73 69 6d 5f 6e 65 74 00 6b 6b 6b a5 vdpasim_net.kkk.<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4e/0x150<br /> [] kstrdup+0x33/0x60<br /> [] kobject_set_name_vargs+0x41/0x110<br /> [] dev_set_name+0xab/0xe0<br /> [] device_add+0xe3/0x1a80<br /> [] 0xffffffffa0270013<br /> [] do_one_initcall+0x87/0x2e0<br /> [] do_init_module+0x1ab/0x640<br /> [] load_module+0x5d00/0x77f0<br /> [] __do_sys_finit_module+0x110/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> (vdpa_sim_blk)<br /> unreferenced object 0xffff8881070c1250 (size 16):<br /> comm "modprobe", pid 6844, jiffies 4364069319 (age 17.572s)<br /> hex dump (first 16 bytes):<br /> 76 64 70 61 73 69 6d 5f 62 6c 6b 00 6b 6b 6b a5 vdpasim_blk.kkk.<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4e/0x150<br /> [] kstrdup+0x33/0x60<br /> [] kobject_set_name_vargs+0x41/0x110<br /> [] dev_set_name+0xab/0xe0<br /> [] device_add+0xe3/0x1a80<br /> [] 0xffffffffa0220013<br /> [] do_one_initcall+0x87/0x2e0<br /> [] do_init_module+0x1ab/0x640<br /> [] load_module+0x5d00/0x77f0<br /> [] __do_sys_finit_module+0x110/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: smsm: Fix refcount leak bugs in qcom_smsm_probe()<br /> <br /> There are two refcount leak bugs in qcom_smsm_probe():<br /> <br /> (1) The &amp;#39;local_node&amp;#39; is escaped out from for_each_child_of_node() as<br /> the break of iteration, we should call of_node_put() for it in error<br /> path or when it is not used anymore.<br /> (2) The &amp;#39;node&amp;#39; is escaped out from for_each_available_child_of_node()<br /> as the &amp;#39;goto&amp;#39;, we should call of_node_put() for it in goto target.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: gadget: Fix use-after-free during usb config switch<br /> <br /> In the process of switching USB config from rndis to other config,<br /> if the hardware does not support the -&gt;pullup callback, or the<br /> hardware encounters a low probability fault, both of them may cause<br /> the -&gt;pullup callback to fail, which will then cause a system panic<br /> (use after free).<br /> <br /> The gadget drivers sometimes need to be unloaded regardless of the<br /> hardware&amp;#39;s behavior.<br /> <br /> Analysis as follows:<br /> =======================================================================<br /> (1) write /config/usb_gadget/g1/UDC "none"<br /> <br /> gether_disconnect+0x2c/0x1f8<br /> rndis_disable+0x4c/0x74<br /> composite_disconnect+0x74/0xb0<br /> configfs_composite_disconnect+0x60/0x7c<br /> usb_gadget_disconnect+0x70/0x124<br /> usb_gadget_unregister_driver+0xc8/0x1d8<br /> gadget_dev_desc_UDC_store+0xec/0x1e4<br /> <br /> (2) rm /config/usb_gadget/g1/configs/b.1/f1<br /> <br /> rndis_deregister+0x28/0x54<br /> rndis_free+0x44/0x7c<br /> usb_put_function+0x14/0x1c<br /> config_usb_cfg_unlink+0xc4/0xe0<br /> configfs_unlink+0x124/0x1c8<br /> vfs_unlink+0x114/0x1dc<br /> <br /> (3) rmdir /config/usb_gadget/g1/functions/rndis.gs4<br /> <br /> panic+0x1fc/0x3d0<br /> do_page_fault+0xa8/0x46c<br /> do_mem_abort+0x3c/0xac<br /> el1_sync_handler+0x40/0x78<br /> 0xffffff801138f880<br /> rndis_close+0x28/0x34<br /> eth_stop+0x74/0x110<br /> dev_close_many+0x48/0x194<br /> rollback_registered_many+0x118/0x814<br /> unregister_netdev+0x20/0x30<br /> gether_cleanup+0x1c/0x38<br /> rndis_attr_release+0xc/0x14<br /> kref_put+0x74/0xb8<br /> configfs_rmdir+0x314/0x374<br /> <br /> If gadget-&gt;ops-&gt;pullup() return an error, function rndis_close() will be<br /> called, then it will causes a use-after-free problem.<br /> =======================================================================

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rw: defer fsnotify calls to task context<br /> <br /> We can&amp;#39;t call these off the kiocb completion as that might be off<br /> soft/hard irq context. Defer the calls to when we process the<br /> task_work for this request. That avoids valid complaints like:<br /> <br /> stack backtrace:<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.0.0-rc6-syzkaller-00321-g105a36f3694e #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_usage_bug kernel/locking/lockdep.c:3961 [inline]<br /> valid_state kernel/locking/lockdep.c:3973 [inline]<br /> mark_lock_irq kernel/locking/lockdep.c:4176 [inline]<br /> mark_lock.part.0.cold+0x18/0xd8 kernel/locking/lockdep.c:4632<br /> mark_lock kernel/locking/lockdep.c:4596 [inline]<br /> mark_usage kernel/locking/lockdep.c:4527 [inline]<br /> __lock_acquire+0x11d9/0x56d0 kernel/locking/lockdep.c:5007<br /> lock_acquire kernel/locking/lockdep.c:5666 [inline]<br /> lock_acquire+0x1ab/0x570 kernel/locking/lockdep.c:5631<br /> __fs_reclaim_acquire mm/page_alloc.c:4674 [inline]<br /> fs_reclaim_acquire+0x115/0x160 mm/page_alloc.c:4688<br /> might_alloc include/linux/sched/mm.h:271 [inline]<br /> slab_pre_alloc_hook mm/slab.h:700 [inline]<br /> slab_alloc mm/slab.c:3278 [inline]<br /> __kmem_cache_alloc_lru mm/slab.c:3471 [inline]<br /> kmem_cache_alloc+0x39/0x520 mm/slab.c:3491<br /> fanotify_alloc_fid_event fs/notify/fanotify/fanotify.c:580 [inline]<br /> fanotify_alloc_event fs/notify/fanotify/fanotify.c:813 [inline]<br /> fanotify_handle_event+0x1130/0x3f40 fs/notify/fanotify/fanotify.c:948<br /> send_to_group fs/notify/fsnotify.c:360 [inline]<br /> fsnotify+0xafb/0x1680 fs/notify/fsnotify.c:570<br /> __fsnotify_parent+0x62f/0xa60 fs/notify/fsnotify.c:230<br /> fsnotify_parent include/linux/fsnotify.h:77 [inline]<br /> fsnotify_file include/linux/fsnotify.h:99 [inline]<br /> fsnotify_access include/linux/fsnotify.h:309 [inline]<br /> __io_complete_rw_common+0x485/0x720 io_uring/rw.c:195<br /> io_complete_rw+0x1a/0x1f0 io_uring/rw.c:228<br /> iomap_dio_complete_work fs/iomap/direct-io.c:144 [inline]<br /> iomap_dio_bio_end_io+0x438/0x5e0 fs/iomap/direct-io.c:178<br /> bio_endio+0x5f9/0x780 block/bio.c:1564<br /> req_bio_endio block/blk-mq.c:695 [inline]<br /> blk_update_request+0x3fc/0x1300 block/blk-mq.c:825<br /> scsi_end_request+0x7a/0x9a0 drivers/scsi/scsi_lib.c:541<br /> scsi_io_completion+0x173/0x1f70 drivers/scsi/scsi_lib.c:971<br /> scsi_complete+0x122/0x3b0 drivers/scsi/scsi_lib.c:1438<br /> blk_complete_reqs+0xad/0xe0 block/blk-mq.c:1022<br /> __do_softirq+0x1d3/0x9c6 kernel/softirq.c:571<br /> invoke_softirq kernel/softirq.c:445 [inline]<br /> __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650<br /> irq_exit_rcu+0x5/0x20 kernel/softirq.c:662<br /> common_interrupt+0xa9/0xc0 arch/x86/kernel/irq.c:240

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ieee802154: don&amp;#39;t warn zero-sized raw_sendmsg()<br /> <br /> syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1],<br /> for PF_IEEE802154 socket&amp;#39;s zero-sized raw_sendmsg() request is hitting<br /> __dev_queue_xmit() with skb-&gt;len == 0.<br /> <br /> Since PF_IEEE802154 socket&amp;#39;s zero-sized raw_sendmsg() request was<br /> able to return 0, don&amp;#39;t call __dev_queue_xmit() if packet length is 0.<br /> <br /> ----------<br /> #include <br /> #include <br /> <br /> int main(int argc, char *argv[])<br /> {<br /> struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };<br /> struct iovec iov = { };<br /> struct msghdr hdr = { .msg_name = &amp;addr, .msg_namelen = sizeof(addr), .msg_iov = &amp;iov, .msg_iovlen = 1 };<br /> sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &amp;hdr, 0);<br /> return 0;<br /> }<br /> ----------<br /> <br /> Note that this might be a sign that commit fd1894224407c484 ("bpf: Don&amp;#39;t<br /> redirect packets with invalid pkt_len") should be reverted, for<br /> skb-&gt;len == 0 was acceptable for at least PF_IEEE802154 socket.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()<br /> <br /> &amp;#39;vc_ctrl_req&amp;#39; is alloced in virtio_crypto_alg_skcipher_close_session(),<br /> and should be freed in the invalid ctrl_status-&gt;status error handling<br /> case. Otherwise there is a memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HSI: ssi_protocol: fix potential resource leak in ssip_pn_open()<br /> <br /> ssip_pn_open() claims the HSI client&amp;#39;s port with hsi_claim_port(). When<br /> hsi_register_port_event() gets some error and returns a negetive value,<br /> the HSI client&amp;#39;s port should be released with hsi_release_port().<br /> <br /> Fix it by calling hsi_release_port() when hsi_register_port_event() fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: da7219: Fix an error handling path in da7219_register_dai_clks()<br /> <br /> If clk_hw_register() fails, the corresponding clk should not be<br /> unregistered.<br /> <br /> To handle errors from loops, clean up partial iterations before doing the<br /> goto. So add a clk_hw_unregister().<br /> Then use a while (--i &gt;= 0) loop in the unwind section.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mrp: introduce active flags to prevent UAF when applicant uninit<br /> <br /> The caller of del_timer_sync must prevent restarting of the timer, If<br /> we have no this synchronization, there is a small probability that the<br /> cancellation will not be successful.<br /> <br /> And syzbot report the fellowing crash:<br /> ==================================================================<br /> BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]<br /> BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605<br /> Write at addr f9ff000024df6058 by task syz-fuzzer/2256<br /> Pointer tag: [f9], memory tag: [fe]<br /> <br /> CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-<br /> ge01d50cbd6ee #0<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156<br /> dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline]<br /> show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163<br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:284 [inline]<br /> print_report+0x1a8/0x4a0 mm/kasan/report.c:395<br /> kasan_report+0x94/0xb4 mm/kasan/report.c:495<br /> __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320<br /> do_bad_area arch/arm64/mm/fault.c:473 [inline]<br /> do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749<br /> do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825<br /> el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367<br /> el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427<br /> el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576<br /> hlist_add_head include/linux/list.h:929 [inline]<br /> enqueue_timer+0x18/0xa4 kernel/time/timer.c:605<br /> mod_timer+0x14/0x20 kernel/time/timer.c:1161<br /> mrp_periodic_timer_arm net/802/mrp.c:614 [inline]<br /> mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627<br /> call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474<br /> expire_timers+0x98/0xc4 kernel/time/timer.c:1519<br /> <br /> To fix it, we can introduce a new active flags to make sure the timer will<br /> not restart.

*** Pendiente de traducción *** Mattermost versions 11.1.x