{"schema_version":"1.7.2","id":"OESA-2025-1247","modified":"2025-03-07T15:27:15Z","published":"2025-03-07T15:27:15Z","upstream":["CVE-2024-56606","CVE-2024-57908","CVE-2024-57912","CVE-2024-57977","CVE-2025-21650","CVE-2025-21651","CVE-2025-21731","CVE-2025-21815"],"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\naf_packet: avoid erroring out after sock_init_data() in packet_create()\n\nAfter sock_init_data() the allocated sk object is attached to the provided\nsock object. On error, packet_create() frees the sk object leaving the\ndangling pointer in the sock object on return. Some other code may try\nto use this pointer and cause use-after-free.(CVE-2024-56606)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: kmx61: fix information leak in triggered buffer\n\nThe \u0026apos;buffer\u0026apos; local array is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the array to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57908)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: pressure: zpa2326: fix information leak in triggered buffer\n\nThe \u0026apos;sample\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it has a hole between the temperature and the\ntimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).\nThis hole is never initialized.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57912)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: fix soft lockup in the OOM process\n\nA soft lockup issue was found in the product with about 56,000 tasks were\nin the OOM cgroup, it was traversing them when the soft lockup was\ntriggered.\n\nwatchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066]\nCPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G\nHardware name: Huawei Cloud OpenStack Nova, BIOS\nRIP: 0010:console_unlock+0x343/0x540\nRSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13\nRAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247\nRBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040\nR10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0\nR13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n vprintk_emit+0x193/0x280\n printk+0x52/0x6e\n dump_task+0x114/0x130\n mem_cgroup_scan_tasks+0x76/0x100\n dump_header+0x1fe/0x210\n oom_kill_process+0xd1/0x100\n out_of_memory+0x125/0x570\n mem_cgroup_out_of_memory+0xb5/0xd0\n try_charge+0x720/0x770\n mem_cgroup_try_charge+0x86/0x180\n mem_cgroup_try_charge_delay+0x1c/0x40\n do_anonymous_page+0xb5/0x390\n handle_mm_fault+0xc4/0x1f0\n\nThis is because thousands of processes are in the OOM cgroup, it takes a\nlong time to traverse all of them.  As a result, this lead to soft lockup\nin the OOM process.\n\nTo fix this issue, call \u0026apos;cond_resched\u0026apos; in the \u0026apos;mem_cgroup_scan_tasks\u0026apos;\nfunction per 1000 iterations.  For global OOM, call\n\u0026apos;touch_softlockup_watchdog\u0026apos; per 1000 iterations to avoid this issue.(CVE-2024-57977)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue\n\nThe TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs\n1024-1279 are in different BAR space addresses. However,\nhclge_fetch_pf_reg does not distinguish the tqp space information when\nreading the tqp space information. When the number of TQPs is greater\nthan 1024, access bar space overwriting occurs.\nThe problem of different segments has been considered during the\ninitialization of tqp.io_base. Therefore, tqp.io_base is directly used\nwhen the queue is read in hclge_fetch_pf_reg.\n\nThe error message:\n\nUnable to handle kernel paging request at virtual address ffff800037200000\npc : hclge_fetch_pf_reg+0x138/0x250 [hclge]\nlr : hclge_get_regs+0x84/0x1d0 [hclge]\nCall trace:\n hclge_fetch_pf_reg+0x138/0x250 [hclge]\n hclge_get_regs+0x84/0x1d0 [hclge]\n hns3_get_regs+0x2c/0x50 [hns3]\n ethtool_get_regs+0xf4/0x270\n dev_ethtool+0x674/0x8a0\n dev_ioctl+0x270/0x36c\n sock_do_ioctl+0x110/0x2a0\n sock_ioctl+0x2ac/0x530\n __arm64_sys_ioctl+0xa8/0x100\n invoke_syscall+0x4c/0x124\n el0_svc_common.constprop.0+0x140/0x15c\n do_el0_svc+0x30/0xd0\n el0_svc+0x1c/0x2c\n el0_sync_handler+0xb0/0xb4\n el0_sync+0x168/0x180(CVE-2025-21650)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: don\u0026apos;t auto enable misc vector\n\nCurrently, there is a time window between misc irq enabled\nand service task inited. If an interrupte is reported at\nthis time, it will cause warning like below:\n\n[   16.324639] Call trace:\n[   16.324641]  __queue_delayed_work+0xb8/0xe0\n[   16.324643]  mod_delayed_work_on+0x78/0xd0\n[   16.324655]  hclge_errhand_task_schedule+0x58/0x90 [hclge]\n[   16.324662]  hclge_misc_irq_handle+0x168/0x240 [hclge]\n[   16.324666]  __handle_irq_event_percpu+0x64/0x1e0\n[   16.324667]  handle_irq_event+0x80/0x170\n[   16.324670]  handle_fasteoi_edge_irq+0x110/0x2bc\n[   16.324671]  __handle_domain_irq+0x84/0xfc\n[   16.324673]  gic_handle_irq+0x88/0x2c0\n[   16.324674]  el1_irq+0xb8/0x140\n[   16.324677]  arch_cpu_idle+0x18/0x40\n[   16.324679]  default_idle_call+0x5c/0x1bc\n[   16.324682]  cpuidle_idle_call+0x18c/0x1c4\n[   16.324684]  do_idle+0x174/0x17c\n[   16.324685]  cpu_startup_entry+0x30/0x6c\n[   16.324687]  secondary_start_kernel+0x1a4/0x280\n[   16.324688] ---[ end trace 6aa0bff672a964aa ]---\n\nSo don\u0026apos;t auto enable misc vector when request irq..(CVE-2025-21651)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: don\u0026apos;t allow reconnect after disconnect\n\nFollowing process can cause nbd_config UAF:\n\n1) grab nbd_config temporarily;\n\n2) nbd_genl_disconnect() flush all recv_work() and release the\ninitial reference:\n\n  nbd_genl_disconnect\n   nbd_disconnect_and_put\n    nbd_disconnect\n     flush_workqueue(nbd-\u0026gt;recv_workq)\n    if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...))\n     nbd_config_put\n     -\u0026gt; due to step 1), reference is still not zero\n\n3) nbd_genl_reconfigure() queue recv_work() again;\n\n  nbd_genl_reconfigure\n   config = nbd_get_config_unlocked(nbd)\n   if (!config)\n   -\u0026gt; succeed\n   if (!test_bit(NBD_RT_BOUND, ...))\n   -\u0026gt; succeed\n   nbd_reconnect_socket\n    queue_work(nbd-\u0026gt;recv_workq, \u0026amp;args-\u0026gt;work)\n\n4) step 1) release the reference;\n\n5) Finially, recv_work() will trigger UAF:\n\n  recv_work\n   nbd_config_put(nbd)\n   -\u0026gt; nbd_config is freed\n   atomic_dec(\u0026amp;config-\u0026gt;recv_threads)\n   -\u0026gt; UAF\n\nFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so\nthat nbd_genl_reconfigure() will fail.(CVE-2025-21731)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/compaction: fix UBSAN shift-out-of-bounds warning\n\nsyzkaller reported a UBSAN shift-out-of-bounds warning of (1UL \u0026lt;\u0026lt; order)\nin isolate_freepages_block().  The bogus compound_order can be any value\nbecause it is union with flags.  Add back the MAX_PAGE_ORDER check to fix\nthe warning.(CVE-2025-21815)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-252.0.0.156.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","perf-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-252.0.0.156.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","perf-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-252.0.0.156.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1247"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-56606"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57908"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57912"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57977"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21650"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21651"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21731"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21815"}],"database_specific":{"severity":"High"}}