{"id":"OESA-2025-1160","summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: t7xx: Fix FSM command timeout issue\n\nWhen driver processes the internal state change command, it use an\nasynchronous thread to process the command operation. If the main\nthread detects that the task has timed out, the asynchronous thread\nwill panic when executing the completion notification because the\nmain thread completion object has been released.\n\nBUG: unable to handle page fault for address: fffffffffffffff8\nPGD 1f283a067 P4D 1f283a067 PUD 1f283c067 PMD 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nRIP: 0010:complete_all+0x3e/0xa0\n[...]\nCall Trace:\n <TASK>\n ? __die_body+0x68/0xb0\n ? page_fault_oops+0x379/0x3e0\n ? exc_page_fault+0x69/0xa0\n ? asm_exc_page_fault+0x22/0x30\n ? complete_all+0x3e/0xa0\n fsm_main_thread+0xa3/0x9c0 [mtk_t7xx (HASH:1400 5)]\n ? __pfx_autoremove_wake_function+0x10/0x10\n kthread+0xd8/0x110\n ? __pfx_fsm_main_thread+0x10/0x10 [mtk_t7xx (HASH:1400 5)]\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x38/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n[...]\nCR2: fffffffffffffff8\n---[ end trace 0000000000000000 ]---\n\nUse the reference counter to ensure safe release as Sergey suggests:\nhttps://lore.kernel.org/all/da90f64c-260a-4329-87bf-1f9ff20a5951@gmail.com/(CVE-2024-39282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni3c: mipi-i3c-hci: Mask ring interrupts before ring stop request\n\nBus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when\nthe ring is being stopped. Depending on timing between ring stop request\ncompletion, interrupt handler removal and code execution this may lead\nto a NULL pointer dereference in hci_dma_irq_handler() if it gets to run\nafter the io_data pointer is set to NULL in hci_dma_cleanup().\n\nPrevent this my masking the ring interrupts before ring stop request.(CVE-2024-45828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nethtool: fail closed if we can't get max channel used in indirection tables\n\nCommit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with\nactive RSS contexts") proves that allowing indirection table to contain\nchannels with out of bounds IDs may lead to crashes. Currently the\nmax channel check in the core gets skipped if driver can't fetch\nthe indirection table or when we can't allocate memory.\n\nBoth of those conditions should be extremely rare but if they do\nhappen we should try to be safe and fail the channel change.(CVE-2024-46834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-rdma: unquiesce admin_q before destroy it\n\nKernel will hang on destroy admin_q while we create ctrl failed, such\nas following calltrace:\n\nPID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: "nvme"\n #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15\n #1 [ff61d23de260fc08] schedule at ffffffff8323c014\n #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1\n #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a\n #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006\n #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce\n #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced\n #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b\n #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362\n #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25\n    RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202\n    RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574\n    RDX: 000000000000012b  RSI: 000055e8122a4d90  RDI: 0000000000000004\n    RBP: 00007ffe2ef079c0   R8: 000000000000012b   R9: 000055e8122a4d90\n    R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000004\n    R13: 000055e8122923c0  R14: 000000000000012b  R15: 00007fda78a54500\n    ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b\n\nThis due to we have quiesced admi_q before cancel requests, but forgot\nto unquiesce before destroy it, as a result we fail to drain the\npending requests, and hang on blk_mq_freeze_queue_wait() forever. Here\ntry to reuse nvme_rdma_teardown_admin_queue() to fix this issue and\nsimplify the code.(CVE-2024-49569)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don't call cleanup on profile rollback failure\n\nWhen profile rollback fails in mlx5e_netdev_change_profile, the netdev\nprofile var is left set to NULL. Avoid a crash when unloading the driver\nby not calling profile->cleanup in such a case.\n\nThis was encountered while testing, with the original trigger that\nthe wq rescuer thread creation got interrupted (presumably due to\nCtrl+C-ing modprobe), which gets converted to ENOMEM (-12) by\nmlx5e_priv_init, the profile rollback also fails for the same reason\n(signal still active) so the profile is left as NULL, leading to a crash\nlater in _mlx5e_remove.\n\n [  732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2)\n [  734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR\n [  734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12\n [  734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12\n [  734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR\n [  734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12\n [  734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n [  745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008\n [  745.538222] #PF: supervisor read access in kernel mode\n<snipped>\n [  745.551290] Call Trace:\n [  745.551590]  <TASK>\n [  745.551866]  ? __die+0x20/0x60\n [  745.552218]  ? page_fault_oops+0x150/0x400\n [  745.555307]  ? exc_page_fault+0x79/0x240\n [  745.555729]  ? asm_exc_page_fault+0x22/0x30\n [  745.556166]  ? mlx5e_remove+0x6b/0xb0 [mlx5_core]\n [  745.556698]  auxiliary_bus_remove+0x18/0x30\n [  745.557134]  device_release_driver_internal+0x1df/0x240\n [  745.557654]  bus_remove_device+0xd7/0x140\n [  745.558075]  device_del+0x15b/0x3c0\n [  745.558456]  mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core]\n [  745.559112]  mlx5_unregister_device+0x34/0x50 [mlx5_core]\n [  745.559686]  mlx5_uninit_one+0x46/0xf0 [mlx5_core]\n [  745.560203]  remove_one+0x4e/0xd0 [mlx5_core]\n [  745.560694]  pci_device_remove+0x39/0xa0\n [  745.561112]  device_release_driver_internal+0x1df/0x240\n [  745.561631]  driver_detach+0x47/0x90\n [  745.562022]  bus_remove_driver+0x84/0x100\n [  745.562444]  pci_unregister_driver+0x3b/0x90\n [  745.562890]  mlx5_cleanup+0xc/0x1b [mlx5_core]\n [  745.563415]  __x64_sys_delete_module+0x14d/0x2f0\n [  745.563886]  ? kmem_cache_free+0x1b0/0x460\n [  745.564313]  ? lockdep_hardirqs_on_prepare+0xe2/0x190\n [  745.564825]  do_syscall_64+0x6d/0x140\n [  745.565223]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n [  745.565725] RIP: 0033:0x7f1579b1288b(CVE-2024-50146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Get rid of userspace_irqchip_in_use\n\nImproper use of userspace_irqchip_in_use led to syzbot hitting the\nfollowing WARN_ON() in kvm_timer_update_irq():\n\nWARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459\nkvm_timer_update_irq+0x21c/0x394\nCall trace:\n  kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459\n  kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968\n  kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264\n  kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline]\n  kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline]\n  kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695\n  kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658\n  vfs_ioctl fs/ioctl.c:51 [inline]\n  __do_sys_ioctl fs/ioctl.c:907 [inline]\n  __se_sys_ioctl fs/ioctl.c:893 [inline]\n  __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893\n  __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n  invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49\n  el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132\n  do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151\n  el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712\n  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\n  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\n\nThe following sequence led to the scenario:\n - Userspace creates a VM and a vCPU.\n - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during\n   KVM_ARM_VCPU_INIT.\n - Without any other setup, such as vGIC or vPMU, userspace issues\n   KVM_RUN on the vCPU. Since the vPMU is requested, but not setup,\n   kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change().\n   As a result, KVM_RUN returns after enabling the timer, but before\n   incrementing 'userspace_irqchip_in_use':\n   kvm_arch_vcpu_run_pid_change()\n       ret = kvm_arm_pmu_v3_enable()\n           if (!vcpu->arch.pmu.created)\n               return -EINVAL;\n       if (ret)\n           return ret;\n       [...]\n       if (!irqchip_in_kernel(kvm))\n           static_branch_inc(&userspace_irqchip_in_use);\n - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again.\n   Since the timer is already enabled, control moves through the\n   following flow, ultimately hitting the WARN_ON():\n   kvm_timer_vcpu_reset()\n       if (timer->enabled)\n          kvm_timer_update_irq()\n              if (!userspace_irqchip())\n                  ret = kvm_vgic_inject_irq()\n                      ret = vgic_lazy_init()\n                          if (unlikely(!vgic_initialized(kvm)))\n                              if (kvm->arch.vgic.vgic_model !=\n                                  KVM_DEV_TYPE_ARM_VGIC_V2)\n                                      return -EBUSY;\n                  WARN_ON(ret);\n\nTheoretically, since userspace_irqchip_in_use's functionality can be\nsimply replaced by '!irqchip_in_kernel()', get rid of the static key\nto avoid the mismanagement, which also helps with the syzbot issue.(CVE-2024-53195)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: IDLETIMER: Fix for possible ABBA deadlock\n\nDeletion of the last rule referencing a given idletimer may happen at\nthe same time as a read of its file in sysfs:\n\n| ======================================================\n| WARNING: possible circular locking dependency detected\n| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted\n| ------------------------------------------------------\n| iptables/3303 is trying to acquire lock:\n| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20\n|\n| but task is already holding lock:\n| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]\n|\n| which lock already depends on the new lock.\n\nA simple reproducer is:\n\n| #!/bin/bash\n|\n| while true; do\n|         iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"\n|         iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"\n| done &\n| while true; do\n|         cat /sys/class/xt_idletimer/timers/testme >/dev/null\n| done\n\nAvoid this by freeing list_mutex right after deleting the element from\nthe list, then continuing with the teardown.(CVE-2024-54683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation\n\nWhen compiling kernel source 'make -j $(nproc)' with the up-and-running\nKASAN-enabled kernel on a 256-core machine, the following soft lockup is\nshown:\n\nwatchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760]\nCPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95\nWorkqueue: events drain_vmap_area_work\nRIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0\nCode: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75\nRSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202\nRAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949\nRDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50\nRBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800\nR10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39\nR13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003\nFS:  0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0\nCall Trace:\n <IRQ>\n ? watchdog_timer_fn+0x2cd/0x390\n ? __pfx_watchdog_timer_fn+0x10/0x10\n ? __hrtimer_run_queues+0x300/0x6d0\n ? sched_clock_cpu+0x69/0x4e0\n ? __pfx___hrtimer_run_queues+0x10/0x10\n ? srso_return_thunk+0x5/0x5f\n ? ktime_get_update_offsets_now+0x7f/0x2a0\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? hrtimer_interrupt+0x2ca/0x760\n ? __sysvec_apic_timer_interrupt+0x8c/0x2b0\n ? sysvec_apic_timer_interrupt+0x6a/0x90\n </IRQ>\n <TASK>\n ? asm_sysvec_apic_timer_interrupt+0x16/0x20\n ? smp_call_function_many_cond+0x1d8/0xbb0\n ? __pfx_do_kernel_range_flush+0x10/0x10\n on_each_cpu_cond_mask+0x20/0x40\n flush_tlb_kernel_range+0x19b/0x250\n ? srso_return_thunk+0x5/0x5f\n ? kasan_release_vmalloc+0xa7/0xc0\n purge_vmap_node+0x357/0x820\n ? __pfx_purge_vmap_node+0x10/0x10\n __purge_vmap_area_lazy+0x5b8/0xa10\n drain_vmap_area_work+0x21/0x30\n process_one_work+0x661/0x10b0\n worker_thread+0x844/0x10e0\n ? srso_return_thunk+0x5/0x5f\n ? __kthread_parkme+0x82/0x140\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2a5/0x370\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nDebugging Analysis:\n\n  1. The following ftrace log shows that the lockup CPU spends too much\n     time iterating vmap_nodes and flushing TLB when purging vm_area\n     structures. (Some info is trimmed).\n\n     kworker: funcgraph_entry:              |  drain_vmap_area_work() {\n     kworker: funcgraph_entry:              |   mutex_lock() {\n     kworker: funcgraph_entry:  1.092 us    |     __cond_resched();\n     kworker: funcgraph_exit:   3.306 us    |   }\n     ...                                        ...\n     kworker: funcgraph_entry:              |    flush_tlb_kernel_range() {\n     ...                                          ...\n     kworker: funcgraph_exit: # 7533.649 us |    }\n     ...                                         ...\n     kworker: funcgraph_entry:  2.344 us    |   mutex_unlock();\n     kworker: funcgraph_exit: $ 23871554 us | }\n\n     The drain_vmap_area_work() spends over 23 seconds.\n\n     There are 2805 flush_tlb_kernel_range() calls in the ftrace log.\n       * One is called in __purge_vmap_area_lazy().\n       * Others are called by purge_vmap_node->kasan_release_vmalloc.\n         purge_vmap_node() iteratively releases kasan vmalloc\n         allocations and flushes TLB for each vmap_area.\n           - [Rough calculation] Each flush_tlb_kernel_range() runs\n             about 7.5ms.\n               -- 2804 * 7.5ms = 21.03 seconds.\n               -- That's why a soft lock is triggered.\n\n  2. Extending the soft lockup time can work around the issue (For example,\n     # echo\n---truncated---(CVE-2024-56559)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngpio: grgpio: Add NULL check in grgpio_probe\n\ndevm_kasprintf() can return a NULL pointer on failure,but this\nreturned value in grgpio_probe is not checked.\nAdd NULL check in grgpio_probe, to handle kernel NULL\npointer dereference error.(CVE-2024-56634)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Fix icmp host relookup triggering ip_rt_bug\n\narp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:\n\nWARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20\nModules linked in:\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:ip_rt_bug+0x14/0x20\nCall Trace:\n <IRQ>\n ip_send_skb+0x14/0x40\n __icmp_send+0x42d/0x6a0\n ipv4_link_failure+0xe2/0x1d0\n arp_error_report+0x3c/0x50\n neigh_invalidate+0x8d/0x100\n neigh_timer_handler+0x2e1/0x330\n call_timer_fn+0x21/0x120\n __run_timer_base.part.0+0x1c9/0x270\n run_timer_softirq+0x4c/0x80\n handle_softirqs+0xac/0x280\n irq_exit_rcu+0x62/0x80\n sysvec_apic_timer_interrupt+0x77/0x90\n\nThe script below reproduces this scenario:\nip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \\\n\tdir out priority 0 ptype main flag localok icmp\nip l a veth1 type veth\nip a a 192.168.141.111/24 dev veth0\nip l s veth0 up\nping 192.168.141.155 -c 1\n\nicmp_route_lookup() create input routes for locally generated packets\nwhile xfrm relookup ICMP traffic.Then it will set input route\n(dst->out = ip_rt_bug) to skb for DESTUNREACH.\n\nFor ICMP err triggered by locally generated packets, dst->dev of output\nroute is loopback. Generally, xfrm relookup verification is not required\non loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).\n\nSkip icmp relookup for locally generated packets to fix it.(CVE-2024-56647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix soft lockups in fib6_select_path under high next hop churn\n\nSoft lockups have been observed on a cluster of Linux-based edge routers\nlocated in a highly dynamic environment. Using the `bird` service, these\nrouters continuously update BGP-advertised routes due to frequently\nchanging nexthop destinations, while also managing significant IPv6\ntraffic. The lockups occur during the traversal of the multipath\ncircular linked-list in the `fib6_select_path` function, particularly\nwhile iterating through the siblings in the list. The issue typically\narises when the nodes of the linked list are unexpectedly deleted\nconcurrently on a different core—indicated by their 'next' and\n'previous' elements pointing back to the node itself and their reference\ncount dropping to zero. This results in an infinite loop, leading to a\nsoft lockup that triggers a system panic via the watchdog timer.\n\nApply RCU primitives in the problematic code sections to resolve the\nissue. Where necessary, update the references to fib6_siblings to\nannotate or use the RCU APIs.\n\nInclude a test script that reproduces the issue. The script\nperiodically updates the routing table while generating a heavy load\nof outgoing IPv6 traffic through multiple iperf3 clients. It\nconsistently induces infinite soft lockups within a couple of minutes.\n\nKernel log:\n\n 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb\n 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3\n 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4\n 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03\n 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f\n 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756\n 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af\n 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d\n-- <IRQ stack> --\n 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb\n    [exception RIP: fib6_select_path+299]\n    RIP: ffffffff8ddafe7b  RSP: ffffbd13003d37b8  RFLAGS: 00000287\n    RAX: ffff975850b43600  RBX: ffff975850b40200  RCX: 0000000000000000\n    RDX: 000000003fffffff  RSI: 0000000051d383e4  RDI: ffff975850b43618\n    RBP: ffffbd13003d3800   R8: 0000000000000000   R9: ffff975850b40200\n    R10: 0000000000000000  R11: 0000000000000000  R12: ffffbd13003d3830\n    R13: ffff975850b436a8  R14: ffff975850b43600  R15: 0000000000000007\n    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c\n10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c\n11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b5\n12 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f47\n13 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d0\n14 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd96274\n15 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd96474\n16 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd96615\n17 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec\n18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b3\n19 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b9\n20 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]\n21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]\n22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]\n23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc18000\n24 [ffffbd13003d3db8] net_rx_action at ffffffff8dc18581\n25 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e9\n26 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe47\n27 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a30\n28 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f\n29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa64\n30 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb(CVE-2024-56703)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: imx8m: Probe the SoC driver as platform driver\n\nWith driver_async_probe=* on kernel command line, the following trace is\nproduced because on i.MX8M Plus hardware because the soc-imx8m.c driver\ncalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock\ndriver is not yet probed. This was not detected during regular testing\nwithout driver_async_probe.\n\nConvert the SoC code to platform driver and instantiate a platform device\nin its current device_initcall() to probe the platform driver. Rework\n.soc_revision callback to always return valid error code and return SoC\nrevision via parameter. This way, if anything in the .soc_revision callback\nreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will get\nretried later.\n\n"\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180\nCPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603\nHardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : imx8mm_soc_revision+0xdc/0x180\nlr : imx8mm_soc_revision+0xd0/0x180\nsp : ffff8000821fbcc0\nx29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120\nx26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311\nx23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb\nx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff\nx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8\nx14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801\nx11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c\nx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3\nx5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb\nCall trace:\n imx8mm_soc_revision+0xdc/0x180\n imx8_soc_init+0xb0/0x1e0\n do_one_initcall+0x94/0x1a8\n kernel_init_freeable+0x240/0x2a8\n kernel_init+0x28/0x140\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\nSoC: i.MX8MP revision 1.1\n"(CVE-2024-56787)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Skip restore TC rules for vport rep without loaded flag\n\nDuring driver unload, unregister_netdev is called after unloading\nvport rep. So, the mlx5e_rep_priv is already freed while trying to get\nrpriv->netdev, or walk rpriv->tc_ht, which results in use-after-free.\nSo add the checking to make sure access the data of vport rep which is\nstill loaded.(CVE-2024-57801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/cpum_sf: Handle CPU hotplug remove during sampling\n\nCPU hotplug remove handling triggers the following function\ncall sequence:\n\n   CPUHP_AP_PERF_S390_SF_ONLINE  --> s390_pmu_sf_offline_cpu()\n   ...\n   CPUHP_AP_PERF_ONLINE          --> perf_event_exit_cpu()\n\nThe s390 CPUMF sampling CPU hotplug handler invokes:\n\n s390_pmu_sf_offline_cpu()\n +-->  cpusf_pmu_setup()\n       +--> setup_pmc_cpu()\n            +--> deallocate_buffers()\n\nThis function de-allocates all sampling data buffers (SDBs) allocated\nfor that CPU at event initialization. It also clears the\nPMU_F_RESERVED bit. The CPU is gone and can not be sampled.\n\nWith the event still being active on the removed CPU, the CPU event\nhotplug support in kernel performance subsystem triggers the\nfollowing function calls on the removed CPU:\n\n  perf_event_exit_cpu()\n  +--> perf_event_exit_cpu_context()\n       +--> __perf_event_exit_context()\n\t    +--> __perf_remove_from_context()\n\t         +--> event_sched_out()\n\t              +--> cpumsf_pmu_del()\n\t                   +--> cpumsf_pmu_stop()\n                                +--> hw_perf_event_update()\n\nto stop and remove the event. During removal of the event, the\nsampling device driver tries to read out the remaining samples from\nthe sample data buffers (SDBs). But they have already been freed\n(and may have been re-assigned). This may lead to a use after free\nsituation in which case the samples are most likely invalid. In the\nbest case the memory has not been reassigned and still contains\nvalid data.\n\nRemedy this situation and check if the CPU is still in reserved\nstate (bit PMU_F_RESERVED set). In this case the SDBs have not been\nreleased an contain valid data. This is always the case when\nthe event is removed (and no CPU hotplug off occured).\nIf the PMU_F_RESERVED bit is not set, the SDB buffers are gone.(CVE-2024-57849)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()\n\nThis will ensure that the scsi host is cleaned up properly using\nscsi_host_dev_release(). Otherwise, it may lead to memory leaks.(CVE-2024-57872)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: seq: oss: Fix races at processing SysEx messages\n\nOSS sequencer handles the SysEx messages split in 6 bytes packets, and\nALSA sequencer OSS layer tries to combine those.  It stores the data\nin the internal buffer and this access is racy as of now, which may\nlead to the out-of-bounds access.\n\nAs a temporary band-aid fix, introduce a mutex for serializing the\nprocess of the SysEx message packets.(CVE-2024-57893)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: at91: call input_free_device() on allocated iio_dev\n\nCurrent implementation of at91_ts_register() calls input_free_deivce()\non st->ts_input, however, the err label can be reached before the\nallocated iio_dev is stored to st->ts_input. Thus call\ninput_free_device() on input instead of st->ts_input.(CVE-2024-57904)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nselinux: ignore unknown extended permissions\n\nWhen evaluating extended permissions, ignore unknown permissions instead\nof calling BUG(). This commit ensures that future permissions can be\nadded without interfering with older kernels.(CVE-2024-57931)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gic-v3-its: Don't enable interrupts in its_irq_set_vcpu_affinity()\n\nThe following call-chain leads to enabling interrupts in a nested interrupt\ndisabled section:\n\nirq_set_vcpu_affinity()\n  irq_get_desc_lock()\n     raw_spin_lock_irqsave()   <--- Disable interrupts\n  its_irq_set_vcpu_affinity()\n     guard(raw_spinlock_irq)   <--- Enables interrupts when leaving the guard()\n  irq_put_desc_unlock()        <--- Warns because interrupts are enabled\n\nThis was broken in commit b97e8a2f7130, which replaced the original\nraw_spin_[un]lock() pair with guard(raw_spinlock_irq).\n\nFix the issue by using guard(raw_spinlock).\n\n[ tglx: Massaged change log ](CVE-2024-57949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: sch_cake: add bounds checks to host bulk flow fairness counts\n\nEven though we fixed a logic error in the commit cited below, syzbot\nstill managed to trigger an underflow of the per-host bulk flow\ncounters, leading to an out of bounds memory access.\n\nTo avoid any such logic errors causing out of bounds memory accesses,\nthis commit factors out all accesses to the per-host bulk flow counters\nto a series of helpers that perform bounds-checking before any\nincrements and decrements. This also has the benefit of improving\nreadability by moving the conditional checks for the flow mode into\nthese helpers, instead of having them spread out throughout the\ncode (which was the cause of the original logic error).\n\nAs part of this change, the flow quantum calculation is consolidated\ninto a helper function, which means that the dithering applied to the\nost load scaling is now applied both in the DRR rotation and when a\nsparse flow's quantum is first initiated. The only user-visible effect\nof this is that the maximum packet size that can be sent while a flow\nstays sparse will now vary with +/- one byte in some cases. This should\nnot make a noticeable difference in practice, and thus it's not worth\ncomplicating the code to preserve the old behaviour.(CVE-2025-21647)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: conntrack: clamp maximum hashtable size to INT_MAX\n\nUse INT_MAX as maximum size for the conntrack hashtable. Otherwise, it\nis possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when\nresizing hashtable because __GFP_NOWARN is unset. See:\n\n  0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")\n\nNote: hashtable resize is only possible from init_netns.(CVE-2025-21648)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute\n\nsyzbot found that TCA_FLOW_RSHIFT attribute was not validated.\nRight shitfing a 32bit integer is undefined for large shift values.\n\nUBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23\nshift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')\nCPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: ipv6_addrconf addrconf_dad_work\nCall Trace:\n <TASK>\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n  ubsan_epilogue lib/ubsan.c:231 [inline]\n  __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468\n  flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329\n  tc_classify include/net/tc_wrapper.h:197 [inline]\n  __tcf_classify net/sched/cls_api.c:1771 [inline]\n  tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867\n  sfb_classify net/sched/sch_sfb.c:260 [inline]\n  sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318\n  dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793\n  __dev_xmit_skb net/core/dev.c:3889 [inline]\n  __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400\n  dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n  neigh_hh_output include/net/neighbour.h:523 [inline]\n  neigh_output include/net/neighbour.h:537 [inline]\n  ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236\n  iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82\n  udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173\n  geneve_xmit_skb drivers/net/geneve.c:916 [inline]\n  geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039\n  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n  netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n  xmit_one net/core/dev.c:3590 [inline]\n  dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606\n  __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434(CVE-2025-21653)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niomap: avoid avoid truncating 64-bit offset to 32 bits\n\non 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a\n32-bit position due to folio_next_index() returning an unsigned long.\nThis could lead to an infinite loop when writing to an xfs filesystem.(CVE-2025-21667)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npmdomain: imx8mp-blk-ctrl: add missing loop break condition\n\nCurrently imx8mp_blk_ctrl_remove() will continue the for loop\nuntil an out-of-bounds exception occurs.\n\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : dev_pm_domain_detach+0x8/0x48\nlr : imx8mp_blk_ctrl_shutdown+0x58/0x90\nsp : ffffffc084f8bbf0\nx29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000\nx26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028\nx23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0\nx20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff\nx17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72\nx14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000\nx11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8\nx8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077\nx2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000\nCall trace:\n dev_pm_domain_detach+0x8/0x48\n platform_shutdown+0x2c/0x48\n device_shutdown+0x158/0x268\n kernel_restart_prepare+0x40/0x58\n kernel_kexec+0x58/0xe8\n __do_sys_reboot+0x198/0x258\n __arm64_sys_reboot+0x2c/0x40\n invoke_syscall+0x5c/0x138\n el0_svc_common.constprop.0+0x48/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x38/0xc8\n el0t_64_sync_handler+0x120/0x130\n el0t_64_sync+0x190/0x198\nCode: 8128c2d0 ffffffc0 aa1e03e9 d503201f(CVE-2025-21668)\n\nIn the Linux kernel, the following vulnerability has been resolved:\nfs/proc: fix softlockup in __read_vmcore (part 2)\nSince commit 5cbcb62dddf5 ("fs/proc: fix softlockup in __read_vmcore") the\nnumber of softlockups in __read_vmcore at kdump time have gone down, but\nthey still happen sometimes.\nIn a memory constrained environment like the kdump image, a softlockup is\nnot just a harmless message, but it can interfere with things like RCU\nfreeing memory, causing the crashdump to get stuck.\nThe second loop in __read_vmcore has a lot more opportunities for natural\nsleep points, like scheduling out while waiting for a data write to\nhappen, but apparently that is not always enough.\nAdd a cond_resched() to the second loop in __read_vmcore to (hopefully)\nget rid of the softlockups.(CVE-2025-21694)","modified":"2026-03-11T07:06:53.538550Z","published":"2025-02-21T13:36:36Z","upstream":["CVE-2024-39282","CVE-2024-45828","CVE-2024-46834","CVE-2024-49569","CVE-2024-50146","CVE-2024-53195","CVE-2024-54683","CVE-2024-56559","CVE-2024-56634","CVE-2024-56647","CVE-2024-56703","CVE-2024-56787","CVE-2024-57801","CVE-2024-57849","CVE-2024-57872","CVE-2024-57893","CVE-2024-57904","CVE-2024-57931","CVE-2024-57949","CVE-2025-21647","CVE-2025-21648","CVE-2025-21653","CVE-2025-21667","CVE-2025-21668","CVE-2025-21694"],"database_specific":{"severity":"High"},"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1160"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39282"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45828"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49569"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50146"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-53195"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-54683"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56559"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56634"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56647"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56703"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56787"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57801"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57849"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57872"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57904"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57931"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21647"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21648"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21653"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21667"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21694"}],"affected":[{"package":{"name":"kernel","ecosystem":"openEuler:24.03-LTS-SP1","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-78.0.0.83.oe2403sp1"}]}],"ecosystem_specific":{"x86_64":["bpftool-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","bpftool-debuginfo-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-debuginfo-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-debugsource-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-devel-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-headers-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-source-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-tools-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-tools-debuginfo-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","kernel-tools-devel-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","perf-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","perf-debuginfo-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","python3-perf-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm","python3-perf-debuginfo-6.6.0-78.0.0.83.oe2403sp1.x86_64.rpm"],"aarch64":["bpftool-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","bpftool-debuginfo-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-debuginfo-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-debugsource-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-devel-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-headers-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-source-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-tools-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-tools-debuginfo-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","kernel-tools-devel-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","perf-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","perf-debuginfo-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","python3-perf-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm","python3-perf-debuginfo-6.6.0-78.0.0.83.oe2403sp1.aarch64.rpm"],"src":["kernel-6.6.0-78.0.0.83.oe2403sp1.src.rpm"]},"database_specific":{"source":"https://repo.openeuler.org/security/data/osv/OESA-2025-1160.json"}}],"schema_version":"1.7.5"}