Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: prevent soft lockup while flush writes<br /> <br /> Currently, there is no limit for raid1/raid10 plugged bio. While flushing<br /> writes, raid1 has cond_resched() while raid10 doesn&amp;#39;t, and too many<br /> writes can cause soft lockup.<br /> <br /> Follow up soft lockup can be triggered easily with writeback test for<br /> raid10 with ramdisks:<br /> <br /> watchdog: BUG: soft lockup - CPU#10 stuck for 27s! [md0_raid10:1293]<br /> Call Trace:<br /> <br /> call_rcu+0x16/0x20<br /> put_object+0x41/0x80<br /> __delete_object+0x50/0x90<br /> delete_object_full+0x2b/0x40<br /> kmemleak_free+0x46/0xa0<br /> slab_free_freelist_hook.constprop.0+0xed/0x1a0<br /> kmem_cache_free+0xfd/0x300<br /> mempool_free_slab+0x1f/0x30<br /> mempool_free+0x3a/0x100<br /> bio_free+0x59/0x80<br /> bio_put+0xcf/0x2c0<br /> free_r10bio+0xbf/0xf0<br /> raid_end_bio_io+0x78/0xb0<br /> one_write_done+0x8a/0xa0<br /> raid10_end_write_request+0x1b4/0x430<br /> bio_endio+0x175/0x320<br /> brd_submit_bio+0x3b9/0x9b7 [brd]<br /> __submit_bio+0x69/0xe0<br /> submit_bio_noacct_nocheck+0x1e6/0x5a0<br /> submit_bio_noacct+0x38c/0x7e0<br /> flush_pending_writes+0xf0/0x240<br /> raid10d+0xac/0x1ed0<br /> <br /> Fix the problem by adding cond_resched() to raid10 like what raid1 did.<br /> <br /> Note that unlimited plugged bio still need to be optimized, for example,<br /> in the case of lots of dirty pages writeback, this will take lots of<br /> memory and io will spend a long time in plug, hence io latency is bad.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix calltrace warning in amddrm_buddy_fini<br /> <br /> The following call trace is observed when removing the amdgpu driver, which<br /> is caused by that BOs allocated for psp are not freed until removing.<br /> <br /> [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]<br /> [61811.450577] Call Trace:<br /> [61811.450577] <br /> [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]<br /> [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu]<br /> [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu]<br /> [61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]<br /> [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu]<br /> [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]<br /> [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm]<br /> [61811.451466] devm_action_release+0x15/0x20<br /> [61811.451469] release_nodes+0x40/0xb0<br /> [61811.451471] devres_release_all+0x9b/0xd0<br /> [61811.451473] __device_release_driver+0x1bb/0x2a0<br /> [61811.451476] driver_detach+0xf3/0x140<br /> [61811.451479] bus_remove_driver+0x6c/0xf0<br /> [61811.451481] driver_unregister+0x31/0x60<br /> [61811.451483] pci_unregister_driver+0x40/0x90<br /> [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]<br /> <br /> For smu v13_0_2, if the GPU supports xgmi, refer to<br /> <br /> commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),<br /> <br /> it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,<br /> which makes all devices in hive list have hw reset but no resume except the<br /> basic ip blocks, then other ip blocks will not call .hw_fini according to<br /> ip_block.status.hw.<br /> <br /> Since psp_free_shared_bufs just includes some software operations, so move<br /> it to psp_sw_fini.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: Fix use after free for wext<br /> <br /> Key information in wext.connect is not reset on (re)connect and can hold<br /> data from a previous connection.<br /> <br /> Reset key data to avoid that drivers or mac80211 incorrectly detect a<br /> WEP connection request and access the freed or already reused memory.<br /> <br /> Additionally optimize cfg80211_sme_connect() and avoid an useless<br /> schedule of conn_work.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: don&amp;#39;t hold ni_lock when calling truncate_setsize()<br /> <br /> syzbot is reporting hung task at do_user_addr_fault() [1], for there is<br /> a silent deadlock between PG_locked bit and ni_lock lock.<br /> <br /> Since filemap_update_page() calls filemap_read_folio() after calling<br /> folio_trylock() which will set PG_locked bit, ntfs_truncate() must not<br /> call truncate_setsize() which will wait for PG_locked bit to be cleared<br /> when holding ni_lock lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: add NULL check in xfrm_update_ae_params<br /> <br /> Normally, x-&gt;replay_esn and x-&gt;preplay_esn should be allocated at<br /> xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the<br /> xfrm_update_ae_params(...) is okay to update them. However, the current<br /> implementation of xfrm_new_ae(...) allows a malicious user to directly<br /> dereference a NULL pointer and crash the kernel like below.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4<br /> RIP: 0010:memcpy_orig+0xad/0x140<br /> Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c<br /> RSP: 0018:ffff888008f57658 EFLAGS: 00000202<br /> RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571<br /> RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818<br /> R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x1e8/0x500<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> ? fixup_exception+0x36/0x460<br /> ? _raw_spin_unlock_irqrestore+0x11/0x40<br /> ? exc_page_fault+0x5e/0xc0<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? xfrm_update_ae_params+0xd1/0x260<br /> ? memcpy_orig+0xad/0x140<br /> ? __pfx__raw_spin_lock_bh+0x10/0x10<br /> xfrm_update_ae_params+0xe7/0x260<br /> xfrm_new_ae+0x298/0x4e0<br /> ? __pfx_xfrm_new_ae+0x10/0x10<br /> ? __pfx_xfrm_new_ae+0x10/0x10<br /> xfrm_user_rcv_msg+0x25a/0x410<br /> ? __pfx_xfrm_user_rcv_msg+0x10/0x10<br /> ? __alloc_skb+0xcf/0x210<br /> ? stack_trace_save+0x90/0xd0<br /> ? filter_irq_stacks+0x1c/0x70<br /> ? __stack_depot_save+0x39/0x4e0<br /> ? __kasan_slab_free+0x10a/0x190<br /> ? kmem_cache_free+0x9c/0x340<br /> ? netlink_recvmsg+0x23c/0x660<br /> ? sock_recvmsg+0xeb/0xf0<br /> ? __sys_recvfrom+0x13c/0x1f0<br /> ? __x64_sys_recvfrom+0x71/0x90<br /> ? do_syscall_64+0x3f/0x90<br /> ? entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> ? copyout+0x3e/0x50<br /> netlink_rcv_skb+0xd6/0x210<br /> ? __pfx_xfrm_user_rcv_msg+0x10/0x10<br /> ? __pfx_netlink_rcv_skb+0x10/0x10<br /> ? __pfx_sock_has_perm+0x10/0x10<br /> ? mutex_lock+0x8d/0xe0<br /> ? __pfx_mutex_lock+0x10/0x10<br /> xfrm_netlink_rcv+0x44/0x50<br /> netlink_unicast+0x36f/0x4c0<br /> ? __pfx_netlink_unicast+0x10/0x10<br /> ? netlink_recvmsg+0x500/0x660<br /> netlink_sendmsg+0x3b7/0x700<br /> <br /> This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit<br /> adds additional NULL check in xfrm_update_ae_params to fix the NPD.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Fix igb_down hung on surprise removal<br /> <br /> In a setup where a Thunderbolt hub connects to Ethernet and a display<br /> through USB Type-C, users may experience a hung task timeout when they<br /> remove the cable between the PC and the Thunderbolt hub.<br /> This is because the igb_down function is called multiple times when<br /> the Thunderbolt hub is unplugged. For example, the igb_io_error_detected<br /> triggers the first call, and the igb_remove triggers the second call.<br /> The second call to igb_down will block at napi_synchronize.<br /> Here&amp;#39;s the call trace:<br /> __schedule+0x3b0/0xddb<br /> ? __mod_timer+0x164/0x5d3<br /> schedule+0x44/0xa8<br /> schedule_timeout+0xb2/0x2a4<br /> ? run_local_timers+0x4e/0x4e<br /> msleep+0x31/0x38<br /> igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> __dev_close_many+0x95/0xec<br /> dev_close_many+0x6e/0x103<br /> unregister_netdevice_many+0x105/0x5b1<br /> unregister_netdevice_queue+0xc2/0x10d<br /> unregister_netdev+0x1c/0x23<br /> igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]<br /> pci_device_remove+0x3f/0x9c<br /> device_release_driver_internal+0xfe/0x1b4<br /> pci_stop_bus_device+0x5b/0x7f<br /> pci_stop_bus_device+0x30/0x7f<br /> pci_stop_bus_device+0x30/0x7f<br /> pci_stop_and_remove_bus_device+0x12/0x19<br /> pciehp_unconfigure_device+0x76/0xe9<br /> pciehp_disable_slot+0x6e/0x131<br /> pciehp_handle_presence_or_link_change+0x7a/0x3f7<br /> pciehp_ist+0xbe/0x194<br /> irq_thread_fn+0x22/0x4d<br /> ? irq_thread+0x1fd/0x1fd<br /> irq_thread+0x17b/0x1fd<br /> ? irq_forced_thread_fn+0x5f/0x5f<br /> kthread+0x142/0x153<br /> ? __irq_get_irqchip_state+0x46/0x46<br /> ? kthread_associate_blkcg+0x71/0x71<br /> ret_from_fork+0x1f/0x30<br /> <br /> In this case, igb_io_error_detected detaches the network interface<br /> and requests a PCIE slot reset, however, the PCIE reset callback is<br /> not being invoked and thus the Ethernet connection breaks down.<br /> As the PCIE error in this case is a non-fatal one, requesting a<br /> slot reset can be avoided.<br /> This patch fixes the task hung issue and preserves Ethernet<br /> connection by ignoring non-fatal PCIE errors.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid deadlock in fs reclaim with page writeback<br /> <br /> Ext4 has a filesystem wide lock protecting ext4_writepages() calls to<br /> avoid races with switching of journalled data flag or inode format. This<br /> lock can however cause a deadlock like:<br /> <br /> CPU0 CPU1<br /> <br /> ext4_writepages()<br /> percpu_down_read(sbi-&gt;s_writepages_rwsem);<br /> ext4_change_inode_journal_flag()<br /> percpu_down_write(sbi-&gt;s_writepages_rwsem);<br /> - blocks, all readers block from now on<br /> ext4_do_writepages()<br /> ext4_init_io_end()<br /> kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)<br /> fs_reclaim frees dentry...<br /> dentry_unlink_inode()<br /> iput() - last ref =&gt;<br /> iput_final() - inode dirty =&gt;<br /> write_inode_now()...<br /> ext4_writepages() tries to acquire sbi-&gt;s_writepages_rwsem<br /> and blocks forever<br /> <br /> Make sure we cannot recurse into filesystem reclaim from writeback code<br /> to avoid the deadlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Pointer may be dereferenced<br /> <br /> Klocwork tool reported pointer &amp;#39;rport&amp;#39; returned from call to function<br /> fc_bsg_to_rport() may be NULL and will be dereferenced.<br /> <br /> Add a fix to validate rport before dereferencing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: make sure skb-&gt;len != 0 when redirecting to a tunneling device<br /> <br /> syzkaller managed to trigger another case where skb-&gt;len == 0<br /> when we enter __dev_queue_xmit:<br /> <br /> WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]<br /> WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295<br /> <br /> Call Trace:<br /> dev_queue_xmit+0x17/0x20 net/core/dev.c:4406<br /> __bpf_tx_skb net/core/filter.c:2115 [inline]<br /> __bpf_redirect_no_mac net/core/filter.c:2140 [inline]<br /> __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163<br /> ____bpf_clone_redirect net/core/filter.c:2447 [inline]<br /> bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419<br /> bpf_prog_48159a89cb4a9a16+0x59/0x5e<br /> bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]<br /> __bpf_prog_run include/linux/filter.h:596 [inline]<br /> bpf_prog_run include/linux/filter.h:603 [inline]<br /> bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402<br /> bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170<br /> bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648<br /> __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005<br /> __do_sys_bpf kernel/bpf/syscall.c:5091 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5089 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089<br /> do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48<br /> entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> The reproducer doesn&amp;#39;t really reproduce outside of syzkaller<br /> environment, so I&amp;#39;m taking a guess here. It looks like we<br /> do generate correct ETH_HLEN-sized packet, but we redirect<br /> the packet to the tunneling device. Before we do so, we<br /> __skb_pull l2 header and arrive again at skb-&gt;len == 0.<br /> Doesn&amp;#39;t seem like we can do anything better than having<br /> an explicit check after __skb_pull?

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ov8865: Fix an error handling path in ov8865_probe()<br /> <br /> The commit in Fixes also introduced some new error handling which should<br /> goto the existing error handling path.<br /> Otherwise some resources leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix reading strings from synthetic events<br /> <br /> The follow commands caused a crash:<br /> <br /> # cd /sys/kernel/tracing<br /> # echo &amp;#39;s:open char file[]&amp;#39; &gt; dynamic_events<br /> # echo &amp;#39;hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)&amp;#39; &gt; events/syscalls/sys_enter_openat/trigger&amp;#39;<br /> # echo 1 &gt; events/synthetic/open/enable<br /> <br /> BOOM!<br /> <br /> The problem is that the synthetic event field "char file[]" will read<br /> the value given to it as a string without any memory checks to make sure<br /> the address is valid. The above example will pass in the user space<br /> address and the sythetic event code will happily call strlen() on it<br /> and then strscpy() where either one will cause an oops when accessing<br /> user space addresses.<br /> <br /> Use the helper functions from trace_kprobe and trace_eprobe that can<br /> read strings safely (and actually succeed when the address is from user<br /> space and the memory is mapped in).<br /> <br /> Now the above can show:<br /> <br /> packagekitd-1721 [000] ...2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr<br /> in:imjournal-978 [006] ...2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp<br /> packagekitd-1721 [000] ...2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: remove drm bridges at aggregate driver unbind time<br /> <br /> drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init<br /> were not manually removed at module unload time, which caused dangling<br /> references to freed memory to remain linked in the global bridge_list.<br /> <br /> When loading the driver modules back in, the same functions would again<br /> call drm_bridge_add, and when traversing the global bridge_list, would<br /> end up peeking into freed memory.<br /> <br /> Once again KASAN revealed the problem:<br /> <br /> [ +0.000095] =============================================================<br /> [ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120<br /> [ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483<br /> <br /> [ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1<br /> [ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT)<br /> [ +0.000008] Call trace:<br /> [ +0.000006] dump_backtrace+0x1ec/0x280<br /> [ +0.000012] show_stack+0x24/0x80<br /> [ +0.000008] dump_stack_lvl+0x98/0xd4<br /> [ +0.000011] print_address_description.constprop.0+0x80/0x520<br /> [ +0.000011] print_report+0x128/0x260<br /> [ +0.000008] kasan_report+0xb8/0xfc<br /> [ +0.000008] __asan_report_load8_noabort+0x3c/0x50<br /> [ +0.000009] __list_add_valid+0x9c/0x120<br /> [ +0.000009] drm_bridge_add+0x6c/0x104 [drm]<br /> [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi]<br /> [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi]<br /> [ +0.000014] component_bind+0x174/0x520<br /> [ +0.000012] component_bind_all+0x1a8/0x38c<br /> [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm]<br /> [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm]<br /> [ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390<br /> [ +0.000010] component_master_add_with_match+0x1c8/0x284<br /> [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm]<br /> [ +0.000026] platform_probe+0xd0/0x220<br /> [ +0.000009] really_probe+0x3ac/0xa80<br /> [ +0.000009] __driver_probe_device+0x1f8/0x400<br /> [ +0.000009] driver_probe_device+0x68/0x1b0<br /> [ +0.000009] __driver_attach+0x20c/0x480<br /> [ +0.000008] bus_for_each_dev+0x114/0x1b0<br /> [ +0.000009] driver_attach+0x48/0x64<br /> [ +0.000008] bus_add_driver+0x390/0x564<br /> [ +0.000009] driver_register+0x1a8/0x3e4<br /> [ +0.000009] __platform_driver_register+0x6c/0x94<br /> [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm]<br /> [ +0.000027] do_one_initcall+0xc4/0x2b0<br /> [ +0.000011] do_init_module+0x154/0x570<br /> [ +0.000011] load_module+0x1a78/0x1ea4<br /> [ +0.000008] __do_sys_init_module+0x184/0x1cc<br /> [ +0.000009] __arm64_sys_init_module+0x78/0xb0<br /> [ +0.000009] invoke_syscall+0x74/0x260<br /> [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260<br /> [ +0.000008] do_el0_svc+0x50/0x70<br /> [ +0.000007] el0_svc+0x68/0x1a0<br /> [ +0.000012] el0t_64_sync_handler+0x11c/0x150<br /> [ +0.000008] el0t_64_sync+0x18c/0x190<br /> <br /> [ +0.000016] Allocated by task 879:<br /> [ +0.000008] kasan_save_stack+0x2c/0x5c<br /> [ +0.000011] __kasan_kmalloc+0x90/0xd0<br /> [ +0.000007] __kmalloc+0x278/0x4a0<br /> [ +0.000011] mpi_resize+0x13c/0x1d0<br /> [ +0.000011] mpi_powm+0xd24/0x1570<br /> [ +0.000009] rsa_enc+0x1a4/0x30c<br /> [ +0.000009] pkcs1pad_verify+0x3f0/0x580<br /> [ +0.000009] public_key_verify_signature+0x7a8/0xba4<br /> [ +0.000010] public_key_verify_signature_2+0x40/0x60<br /> [ +0.000008] verify_signature+0xb4/0x114<br /> [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574<br /> [ +0.000009] pkcs7_validate_trust+0xb8/0x15c<br /> [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0<br /> [ +0.000012] verify_pkcs7_signature+0x78/0xac<br /> [ +0.000007] mod_verify_sig+0x110/0x190<br /> [ +0.000009] module_sig_check+0x114/0x1e0<br /> [ +0.000009] load_module+0xa0/0x1ea4<br /> [ +0.000008] __do_sys_init_module+0x184/0x1cc<br /> [ +0.000008] __arm64_sys_init_module+0x78/0xb0<br /> [ +0.000008] invoke_syscall+0x74/0x260<br /> [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260<br /> [ +0.000008] do_el0_svc+0x50/0x70<br /> [ +0.000007] el0_svc+0x68/0x1a0<br /> [ +0.000009] el0t_64_sync_handler+0x11c/0x150<br /> [ +0.000009] el0t_64<br /> ---truncated---