{"schema_version":"1.7.2","id":"OESA-2025-1571","modified":"2025-05-30T13:48:28Z","published":"2025-05-30T13:48:28Z","upstream":["CVE-2022-3238","CVE-2023-53061","CVE-2023-53073","CVE-2024-57876","CVE-2024-58097","CVE-2025-37773","CVE-2025-37782","CVE-2025-37925","CVE-2025-37940","CVE-2025-37980"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nA double-free flaw was found in the Linux kernel’s NTFS3 subsystem in how a user triggers remount and umount simultaneously. This flaw allows a local user to crash or potentially escalate their privileges on the system.(CVE-2022-3238)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix possible refcount leak in smb2_open()\n\nReference count of acls will leak when memory allocation fails. Fix this\nby adding the missing posix_acl_release().(CVE-2023-53061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd/core: Always clear status for idx\n\nThe variable \u0026apos;status\u0026apos; (which contains the unhandled overflow bits) is\nnot being properly masked in some cases, displaying the following\nwarning:\n\n  WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270\n\nThis seems to be happening because the loop is being continued before\nthe status bit being unset, in case x86_perf_event_set_period()\nreturns 0. This is also causing an inconsistency because the \u0026quot;handled\u0026quot;\ncounter is incremented, but the status bit is not cleaned.\n\nMove the bit cleaning together above, together when the \u0026quot;handled\u0026quot;\ncounter is incremented.(CVE-2023-53073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix resetting msg rx state after topology removal\n\nIf the MST topology is removed during the reception of an MST down reply\nor MST up request sideband message, the\ndrm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset\nfrom one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with\nthe reading/parsing of the message from another thread via\ndrm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is\npossible since the reader/parser doesn\u0026apos;t hold any lock while accessing\nthe reception state. This in turn can lead to a memory corruption in the\nreader/parser as described by commit bd2fccac61b4 (\u0026quot;drm/dp_mst: Fix MST\nsideband message body length check\u0026quot;).\n\nFix the above by resetting the message reception state if needed before\nreading/parsing a message. Another solution would be to hold the\ndrm_dp_mst_topology_mgr::lock for the whole duration of the message\nreception/parsing in drm_dp_mst_handle_down_rep() and\ndrm_dp_mst_handle_up_req(), however this would require a bigger change.\nSince the fix is also needed for stable, opting for the simpler solution\nin this patch.(CVE-2024-57876)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix RCU stall while reaping monitor destination ring\n\nWhile processing the monitor destination ring, MSDUs are reaped from the\nlink descriptor based on the corresponding buf_id.\n\nHowever, sometimes the driver cannot obtain a valid buffer corresponding\nto the buf_id received from the hardware. This causes an infinite loop\nin the destination processing, resulting in a kernel crash.\n\nkernel log:\nath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309\nath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed\nath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309\nath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed\n\nFix this by skipping the problematic buf_id and reaping the next entry,\nreplacing the break with the next MSDU processing.\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58097)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvirtiofs: add filesystem context source name check\n\nIn certain scenarios, for example, during fuzz testing, the source\nname may be NULL, which could lead to a kernel panic. Therefore, an\nextra check for the source name should be added.(CVE-2025-37773)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key\n\nSyzbot reported an issue in hfs subsystem:\n\nBUG: KASAN: slab-out-of-bounds in memcpy_from_page include/linux/highmem.h:423 [inline]\nBUG: KASAN: slab-out-of-bounds in hfs_bnode_read fs/hfs/bnode.c:35 [inline]\nBUG: KASAN: slab-out-of-bounds in hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70\nWrite of size 94 at addr ffff8880123cd100 by task syz-executor237/5102\n\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n memcpy_from_page include/linux/highmem.h:423 [inline]\n hfs_bnode_read fs/hfs/bnode.c:35 [inline]\n hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70\n hfs_brec_insert+0x7f3/0xbd0 fs/hfs/brec.c:159\n hfs_cat_create+0x41d/0xa50 fs/hfs/catalog.c:118\n hfs_mkdir+0x6c/0xe0 fs/hfs/dir.c:232\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdir fs/namei.c:4300 [inline]\n __se_sys_mkdir fs/namei.c:4298 [inline]\n __x64_sys_mkdir+0x6c/0x80 fs/namei.c:4298\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fbdd6057a99\n\nAdd a check for key length in hfs_bnode_read_key to prevent\nout-of-bounds memory access. If the key length is invalid, the\nkey buffer is cleared, improving stability and reliability.(CVE-2025-37782)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: reject on-disk inodes of an unsupported type\n\nSyzbot has reported the following BUG:\n\nkernel BUG at fs/inode.c:668!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014\nRIP: 0010:clear_inode+0x168/0x190\nCode: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7\n 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f\nRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093\nRAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38\nR10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000\nR13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80\nFS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x5f/0xb0\n ? die+0x9e/0xc0\n ? do_trap+0x15a/0x3a0\n ? clear_inode+0x168/0x190\n ? do_error_trap+0x1dc/0x2c0\n ? clear_inode+0x168/0x190\n ? __pfx_do_error_trap+0x10/0x10\n ? report_bug+0x3cd/0x500\n ? handle_invalid_op+0x34/0x40\n ? clear_inode+0x168/0x190\n ? exc_invalid_op+0x38/0x50\n ? asm_exc_invalid_op+0x1a/0x20\n ? clear_inode+0x57/0x190\n ? clear_inode+0x167/0x190\n ? clear_inode+0x168/0x190\n ? clear_inode+0x167/0x190\n jfs_evict_inode+0xb5/0x440\n ? __pfx_jfs_evict_inode+0x10/0x10\n evict+0x4ea/0x9b0\n ? __pfx_evict+0x10/0x10\n ? iput+0x713/0xa50\n txUpdateMap+0x931/0xb10\n ? __pfx_txUpdateMap+0x10/0x10\n jfs_lazycommit+0x49a/0xb80\n ? _raw_spin_unlock_irqrestore+0x8f/0x140\n ? lockdep_hardirqs_on+0x99/0x150\n ? __pfx_jfs_lazycommit+0x10/0x10\n ? __pfx_default_wake_function+0x10/0x10\n ? __kthread_parkme+0x169/0x1d0\n ? __pfx_jfs_lazycommit+0x10/0x10\n kthread+0x2f2/0x390\n ? __pfx_jfs_lazycommit+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x4d/0x80\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nThis happens when \u0026apos;clear_inode()\u0026apos; makes an attempt to finalize an underlying\nJFS inode of unknown type. According to JFS layout description from\nhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to\n15 are reserved for future extensions and should not be encountered on a valid\nfilesystem. So add an extra check for valid inode type in \u0026apos;copy_from_dinode()\u0026apos;.(CVE-2025-37925)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Add cond_resched() to ftrace_graph_set_hash()\n\nWhen the kernel contains a large number of functions that can be traced,\nthe loop in ftrace_graph_set_hash() may take a lot of time to execute.\nThis may trigger the softlockup watchdog.\n\nAdd cond_resched() within the loop to allow the kernel to remain\nresponsive even when processing a large number of functions.\n\nThis matches the cond_resched() that is used in other locations of the\ncode that iterates over all functions that can be traced.(CVE-2025-37940)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix resource leak in blk_register_queue() error path\n\nWhen registering a queue fails after blk_mq_sysfs_register() is\nsuccessful but the function later encounters an error, we need\nto clean up the blk_mq_sysfs resources.\n\nAdd the missing blk_mq_sysfs_unregister() call in the error path\nto properly clean up these resources and prevent a memory leak.(CVE-2025-37980)","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-265.0.0.168.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","perf-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-265.0.0.168.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","perf-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-265.0.0.168.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1571"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-3238"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53061"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-53073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-57876"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-58097"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37773"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37782"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37925"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37940"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37980"}],"database_specific":{"severity":"High"}}