Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp5: Don&amp;#39;t leak some plane state<br /> <br /> Apparently no one noticed that mdp5 plane states leak like a sieve<br /> ever since we introduced plane_state-&gt;commit refcount a few years ago<br /> in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too<br /> early by tracking commits, v3.")<br /> <br /> Fix it by using the right helpers.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/551236/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()<br /> <br /> Change logging from drm_{err,info}() to dev_{err,info}() in functions<br /> mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be<br /> essential to avoid getting NULL pointer kernel panics if any kind<br /> of error happens during AUX transfers happening before the bridge<br /> is attached.<br /> <br /> This may potentially start happening in a later commit implementing<br /> aux-bus support, as AUX transfers will be triggered from the panel<br /> driver (for EDID) before the mtk-dp bridge gets attached, and it&amp;#39;s<br /> done in preparation for the same.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc: Don&amp;#39;t try to copy PPR for task with NULL pt_regs<br /> <br /> powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which<br /> from my (arguably very short) checking is not commonly done for other<br /> archs. This is fine, except when PF_IO_WORKER&amp;#39;s have been created and<br /> the task does something that causes a coredump to be generated. Then we<br /> get this crash:<br /> <br /> Kernel attempted to read user page (160) - exploit attempt? (uid: 1000)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000160<br /> Faulting instruction address: 0xc0000000000c3a60<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries<br /> Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod<br /> CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88<br /> Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries<br /> NIP: c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0<br /> REGS: c0000000041833b0 TRAP: 0300 Not tainted (6.3.0-rc2+)<br /> MSR: 800000000280b033 CR: 88082828 XER: 200400f8<br /> ...<br /> NIP memcpy_power7+0x200/0x7d0<br /> LR ppr_get+0x64/0xb0<br /> Call Trace:<br /> ppr_get+0x40/0xb0 (unreliable)<br /> __regset_get+0x180/0x1f0<br /> regset_get_alloc+0x64/0x90<br /> elf_core_dump+0xb98/0x1b60<br /> do_coredump+0x1c34/0x24a0<br /> get_signal+0x71c/0x1410<br /> do_notify_resume+0x140/0x6f0<br /> interrupt_exit_user_prepare_main+0x29c/0x320<br /> interrupt_exit_user_prepare+0x6c/0xa0<br /> interrupt_return_srr_user+0x8/0x138<br /> <br /> Because ppr_get() is trying to copy from a PF_IO_WORKER with a NULL<br /> pt_regs.<br /> <br /> Check for a valid pt_regs in both ppc_get/ppr_set, and return an error<br /> if not set. The actual error value doesn&amp;#39;t seem to be important here, so<br /> just pick -EINVAL.<br /> <br /> [mpe: Trim oops in change log, add Fixes &amp; Cc stable]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd/selftest: Catch overflow of uptr and length<br /> <br /> syzkaller hits a WARN_ON when trying to have a uptr close to UINTPTR_MAX:<br /> <br /> WARNING: CPU: 1 PID: 393 at drivers/iommu/iommufd/selftest.c:403 iommufd_test+0xb19/0x16f0<br /> Modules linked in:<br /> CPU: 1 PID: 393 Comm: repro Not tainted 6.2.0-c9c3395d5e3d #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:iommufd_test+0xb19/0x16f0<br /> Code: 94 c4 31 ff 44 89 e6 e8 a5 54 17 ff 45 84 e4 0f 85 bb 0b 00 00 41 be fb ff ff ff e8 31 53 17 ff e9 a0 f7 ff ff e8 27 53 17 ff 0b 41 be 8<br /> RSP: 0018:ffffc90000eabdc0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8214c487<br /> RDX: 0000000000000000 RSI: ffff88800f5c8000 RDI: 0000000000000002<br /> RBP: ffffc90000eabe48 R08: 0000000000000000 R09: 0000000000000001<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 00000000cd2b0000<br /> R13: 00000000cd2af000 R14: 0000000000000000 R15: ffffc90000eabe68<br /> FS: 00007f94d76d5740(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000043 CR3: 0000000006880006 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? write_comp_data+0x2f/0x90<br /> iommufd_fops_ioctl+0x1ef/0x310<br /> __x64_sys_ioctl+0x10e/0x160<br /> ? __pfx_iommufd_fops_ioctl+0x10/0x10<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Check that the user memory range doesn&amp;#39;t overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix net_dev_start_xmit trace event vs skb_transport_offset()<br /> <br /> After blamed commit, we must be more careful about using<br /> skb_transport_offset(), as reminded us by syzbot:<br /> <br /> WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]<br /> WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14<br /> Modules linked in:<br /> CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023<br /> Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet<br /> RIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]<br /> RIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]<br /> RIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14<br /> Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff<br /> RSP: 0018:ffffc900002bf700 EFLAGS: 00010293<br /> RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280<br /> RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff<br /> RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e<br /> R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67<br /> R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> [] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline]<br /> [] xmit_one net/core/dev.c:3643 [inline]<br /> [] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660<br /> [] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324<br /> [] dev_queue_xmit include/linux/netdevice.h:3030 [inline]<br /> [] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108<br /> [] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127<br /> [] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline]<br /> [] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline]<br /> [] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701<br /> [] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289<br /> [] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix wrong setting of max_corr_read_errors<br /> <br /> There is no input check when echo md/max_read_errors and overflow might<br /> occur. Add check of input number.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev/ep93xx-fb: Do not assign to struct fb_info.dev<br /> <br /> Do not assing the Linux device to struct fb_info.dev. The call to<br /> register_framebuffer() initializes the field to the fbdev device.<br /> Drivers should not override its value.<br /> <br /> Fixes a bug where the driver incorrectly decreases the hardware<br /> device&amp;#39;s reference counter and leaks the fbdev device.<br /> <br /> v2:<br /> * add Fixes tag (Dan)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: Fix SKB corruption in REO destination ring<br /> <br /> While running traffics for a long time, randomly an RX descriptor<br /> filled with value "0" from REO destination ring is received.<br /> This descriptor which is invalid causes the wrong SKB (SKB stored in<br /> the IDR lookup with buffer id "0") to be fetched which in turn<br /> causes SKB memory corruption issue and the same leads to crash<br /> after some time.<br /> <br /> Changed the start id for idr allocation to "1" and the buffer id "0"<br /> is reserved for error validation. Introduced Sanity check to validate<br /> the descriptor, before processing the SKB.<br /> <br /> Crash Signature :<br /> <br /> Unable to handle kernel paging request at virtual address 3f004900<br /> PC points to "b15_dma_inv_range+0x30/0x50"<br /> LR points to "dma_cache_maint_page+0x8c/0x128".<br /> The Backtrace obtained is as follows:<br /> [] (b15_dma_inv_range) from [] (dma_cache_maint_page+0x8c/0x128)<br /> [] (dma_cache_maint_page) from [] (__dma_page_dev_to_cpu+0x28/0xcc)<br /> [] (__dma_page_dev_to_cpu) from [] (ath11k_dp_process_rx+0x1e8/0x4a4 [ath11k])<br /> [] (ath11k_dp_process_rx [ath11k]) from [] (ath11k_dp_service_srng+0xb0/0x2ac [ath11k])<br /> [] (ath11k_dp_service_srng [ath11k]) from [] (ath11k_pci_ext_grp_napi_poll+0x1c/0x78 [ath11k_pci])<br /> [] (ath11k_pci_ext_grp_napi_poll [ath11k_pci]) from [] (__napi_poll+0x28/0xb8)<br /> [] (__napi_poll) from [] (net_rx_action+0xf0/0x280)<br /> [] (net_rx_action) from [] (__do_softirq+0xd0/0x280)<br /> [] (__do_softirq) from [] (irq_exit+0x74/0xd4)<br /> [] (irq_exit) from [] (__handle_domain_irq+0x90/0xb4)<br /> [] (__handle_domain_irq) from [] (gic_handle_irq+0x58/0x90)<br /> [] (gic_handle_irq) from [] (__irq_svc+0x58/0x8c)<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: Free resources after unregistering them<br /> <br /> The DP component&amp;#39;s unbind operation walks through the submodules to<br /> unregister and clean things up. But if the unbind happens because the DP<br /> controller itself is being removed, all the memory for those submodules<br /> has just been freed.<br /> <br /> Change the order of these operations to avoid the many use-after-free<br /> that otherwise happens in this code path.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/542166/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix WARNING in mb_find_extent<br /> <br /> Syzbot found the following issue:<br /> <br /> EXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!<br /> EXT4-fs (loop0): orphan cleanup on readonly fs<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30<br /> Modules linked in:<br /> CPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> RIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869<br /> RSP: 0018:ffffc90003c9e098 EFLAGS: 00010293<br /> RAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0<br /> RDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040<br /> RBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402<br /> R10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000<br /> R13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc<br /> FS: 0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307<br /> ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735<br /> ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605<br /> ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286<br /> ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651<br /> ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864<br /> ext4_bread+0x2a/0x170 fs/ext4/inode.c:920<br /> ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105<br /> write_blk fs/quota/quota_tree.c:64 [inline]<br /> get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130<br /> do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340<br /> do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375<br /> do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375<br /> do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375<br /> dq_insert_tree fs/quota/quota_tree.c:401 [inline]<br /> qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420<br /> v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358<br /> dquot_acquire+0x348/0x670 fs/quota/dquot.c:444<br /> ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740<br /> dqget+0x999/0xdc0 fs/quota/dquot.c:914<br /> __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492<br /> ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329<br /> ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474<br /> __ext4_fill_super fs/ext4/super.c:5516 [inline]<br /> ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644<br /> get_tree_bdev+0x400/0x620 fs/super.c:1282<br /> vfs_get_tree+0x88/0x270 fs/super.c:1489<br /> do_new_mount+0x289/0xad0 fs/namespace.c:3145<br /> do_mount fs/namespace.c:3488 [inline]<br /> __do_sys_mount fs/namespace.c:3697 [inline]<br /> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Add some debug information:<br /> mb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7<br /> block_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> <br /> Acctually, blocks per group is 64, but block bitmap indicate at least has<br /> 128 blocks. Now, ext4_validate_block_bitmap() didn&amp;#39;t check invalid block&amp;#39;s<br /> bitmap if set.<br /> To resolve above issue, add check like fsck "Padding at end of block bitmap is<br /> not set".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> recordmcount: Fix memory leaks in the uwrite function<br /> <br /> Common realloc mistake: &amp;#39;file_append&amp;#39; nulled but not freed upon failure

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Handle kvm_arm_init failure correctly in finalize_pkvm<br /> <br /> Currently there is no synchronisation between finalize_pkvm() and<br /> kvm_arm_init() initcalls. The finalize_pkvm() proceeds happily even if<br /> kvm_arm_init() fails resulting in the following warning on all the CPUs<br /> and eventually a HYP panic:<br /> <br /> | kvm [1]: IPA Size Limit: 48 bits<br /> | kvm [1]: Failed to init hyp memory protection<br /> | kvm [1]: error initializing Hyp mode: -22<br /> |<br /> | <br /> |<br /> | WARNING: CPU: 0 PID: 0 at arch/arm64/kvm/pkvm.c:226 _kvm_host_prot_finalize+0x30/0x50<br /> | Modules linked in:<br /> | CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0 #237<br /> | Hardware name: FVP Base RevC (DT)<br /> | pstate: 634020c5 (nZCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> | pc : _kvm_host_prot_finalize+0x30/0x50<br /> | lr : __flush_smp_call_function_queue+0xd8/0x230<br /> |<br /> | Call trace:<br /> | _kvm_host_prot_finalize+0x3c/0x50<br /> | on_each_cpu_cond_mask+0x3c/0x6c<br /> | pkvm_drop_host_privileges+0x4c/0x78<br /> | finalize_pkvm+0x3c/0x5c<br /> | do_one_initcall+0xcc/0x240<br /> | do_initcall_level+0x8c/0xac<br /> | do_initcalls+0x54/0x94<br /> | do_basic_setup+0x1c/0x28<br /> | kernel_init_freeable+0x100/0x16c<br /> | kernel_init+0x20/0x1a0<br /> | ret_from_fork+0x10/0x20<br /> | Failed to finalize Hyp protection: -22<br /> | dtb=fvp-base-revc.dtb<br /> | kvm [95]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:540!<br /> | kvm [95]: nVHE call trace:<br /> | kvm [95]: [] __kvm_nvhe_hyp_panic+0xac/0xf8<br /> | kvm [95]: [] __kvm_nvhe_handle_host_mem_abort+0x1a0/0x2ac<br /> | kvm [95]: [] __kvm_nvhe_handle_trap+0x4c/0x160<br /> | kvm [95]: [] __kvm_nvhe___skip_pauth_save+0x4/0x4<br /> | kvm [95]: ---[ end nVHE call trace ]---<br /> | kvm [95]: Hyp Offset: 0xfffe8db00ffa0000<br /> | Kernel panic - not syncing: HYP panic:<br /> | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800<br /> | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000<br /> | VCPU:0000000000000000<br /> | CPU: 3 PID: 95 Comm: kworker/u16:2 Tainted: G W 6.4.0 #237<br /> | Hardware name: FVP Base RevC (DT)<br /> | Workqueue: rpciod rpc_async_schedule<br /> | Call trace:<br /> | dump_backtrace+0xec/0x108<br /> | show_stack+0x18/0x2c<br /> | dump_stack_lvl+0x50/0x68<br /> | dump_stack+0x18/0x24<br /> | panic+0x138/0x33c<br /> | nvhe_hyp_panic_handler+0x100/0x184<br /> | new_slab+0x23c/0x54c<br /> | ___slab_alloc+0x3e4/0x770<br /> | kmem_cache_alloc_node+0x1f0/0x278<br /> | __alloc_skb+0xdc/0x294<br /> | tcp_stream_alloc_skb+0x2c/0xf0<br /> | tcp_sendmsg_locked+0x3d0/0xda4<br /> | tcp_sendmsg+0x38/0x5c<br /> | inet_sendmsg+0x44/0x60<br /> | sock_sendmsg+0x1c/0x34<br /> | xprt_sock_sendmsg+0xdc/0x274<br /> | xs_tcp_send_request+0x1ac/0x28c<br /> | xprt_transmit+0xcc/0x300<br /> | call_transmit+0x78/0x90<br /> | __rpc_execute+0x114/0x3d8<br /> | rpc_async_schedule+0x28/0x48<br /> | process_one_work+0x1d8/0x314<br /> | worker_thread+0x248/0x474<br /> | kthread+0xfc/0x184<br /> | ret_from_fork+0x10/0x20<br /> | SMP: stopping secondary CPUs<br /> | Kernel Offset: 0x57c5cb460000 from 0xffff800080000000<br /> | PHYS_OFFSET: 0x80000000<br /> | CPU features: 0x00000000,1035b7a3,ccfe773f<br /> | Memory Limit: none<br /> | ---[ end Kernel panic - not syncing: HYP panic:<br /> | PS:a34023c9 PC:0000f250710b973c ESR:00000000f2000800<br /> | FAR:ffff000800cb00d0 HPFAR:000000000880cb00 PAR:0000000000000000<br /> | VCPU:0000000000000000 ]---<br /> <br /> Fix it by checking for the successfull initialisation of kvm_arm_init()<br /> in finalize_pkvm() before proceeding any futher.