{"schema_version":"1.7.2","id":"OESA-2025-1570","modified":"2025-05-30T13:48:23Z","published":"2025-05-30T13:48:23Z","upstream":["CVE-2022-3238","CVE-2022-49781","CVE-2022-49784","CVE-2023-53061","CVE-2023-53073","CVE-2023-53146","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\nperf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling\n\namd_pmu_enable_all() does:\n\n      if (!test_bit(idx, cpuc-\u0026gt;active_mask))\n              continue;\n\n      amd_pmu_enable_event(cpuc-\u0026gt;events[idx]);\n\nA perf NMI of another event can come between these two steps. Perf NMI\nhandler internally disables and enables _all_ events, including the one\nwhich nmi-intercepted amd_pmu_enable_all() was in process of enabling.\nIf that unintentionally enabled event has very low sampling period and\ncauses immediate successive NMI, causing the event to be throttled,\ncpuc-\u0026gt;events[idx] and cpuc-\u0026gt;active_mask gets cleared by x86_pmu_stop().\nThis will result in amd_pmu_enable_event() getting called with event=NULL\nwhen amd_pmu_enable_all() resumes after handling the NMIs. This causes a\nkernel crash:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000198\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   amd_pmu_enable_all+0x68/0xb0\n   ctx_resched+0xd9/0x150\n   event_function+0xb8/0x130\n   ? hrtimer_start_range_ns+0x141/0x4a0\n   ? perf_duration_warn+0x30/0x30\n   remote_function+0x4d/0x60\n   __flush_smp_call_function_queue+0xc4/0x500\n   flush_smp_call_function_queue+0x11d/0x1b0\n   do_idle+0x18f/0x2d0\n   cpu_startup_entry+0x19/0x20\n   start_secondary+0x121/0x160\n   secondary_startup_64_no_verify+0xe5/0xeb\n   \u0026lt;/TASK\u0026gt;\n\namd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler\nwere recently added as part of BRS enablement but I\u0026apos;m not sure whether\nwe really need them. We can just disable BRS in the beginning and enable\nit back while returning from NMI. This will solve the issue by not\nenabling those events whose active_masks are set but are not yet enabled\nin hw pmu.(CVE-2022-49781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd/uncore: Fix memory leak for events array\n\nWhen a CPU comes online, the per-CPU NB and LLC uncore contexts are\nfreed but not the events array within the context structure. This\ncauses a memory leak as identified by the kmemleak detector.\n\n  [...]\n  unreferenced object 0xffff8c5944b8e320 (size 32):\n    comm \u0026quot;swapper/0\u0026quot;, pid 1, jiffies 4294670387 (age 151.072s)\n    hex dump (first 32 bytes):\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [\u0026lt;000000000759fb79\u0026gt;] amd_uncore_cpu_up_prepare+0xaf/0x230\n      [\u0026lt;00000000ddc9e126\u0026gt;] cpuhp_invoke_callback+0x2cf/0x470\n      [\u0026lt;0000000093e727d4\u0026gt;] cpuhp_issue_call+0x14d/0x170\n      [\u0026lt;0000000045464d54\u0026gt;] __cpuhp_setup_state_cpuslocked+0x11e/0x330\n      [\u0026lt;0000000069f67cbd\u0026gt;] __cpuhp_setup_state+0x6b/0x110\n      [\u0026lt;0000000015365e0f\u0026gt;] amd_uncore_init+0x260/0x321\n      [\u0026lt;00000000089152d2\u0026gt;] do_one_initcall+0x3f/0x1f0\n      [\u0026lt;000000002d0bd18d\u0026gt;] kernel_init_freeable+0x1ca/0x212\n      [\u0026lt;0000000030be8dde\u0026gt;] kernel_init+0x11/0x120\n      [\u0026lt;0000000059709e59\u0026gt;] ret_from_fork+0x22/0x30\n  unreferenced object 0xffff8c5944b8dd40 (size 64):\n    comm \u0026quot;swapper/0\u0026quot;, pid 1, jiffies 4294670387 (age 151.072s)\n    hex dump (first 32 bytes):\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [\u0026lt;00000000306efe8b\u0026gt;] amd_uncore_cpu_up_prepare+0x183/0x230\n      [\u0026lt;00000000ddc9e126\u0026gt;] cpuhp_invoke_callback+0x2cf/0x470\n      [\u0026lt;0000000093e727d4\u0026gt;] cpuhp_issue_call+0x14d/0x170\n      [\u0026lt;0000000045464d54\u0026gt;] __cpuhp_setup_state_cpuslocked+0x11e/0x330\n      [\u0026lt;0000000069f67cbd\u0026gt;] __cpuhp_setup_state+0x6b/0x110\n      [\u0026lt;0000000015365e0f\u0026gt;] amd_uncore_init+0x260/0x321\n      [\u0026lt;00000000089152d2\u0026gt;] do_one_initcall+0x3f/0x1f0\n      [\u0026lt;000000002d0bd18d\u0026gt;] kernel_init_freeable+0x1ca/0x212\n      [\u0026lt;0000000030be8dde\u0026gt;] kernel_init+0x11/0x120\n      [\u0026lt;0000000059709e59\u0026gt;] ret_from_fork+0x22/0x30\n  [...]\n\nFix the problem by freeing the events array before freeing the uncore\ncontext.(CVE-2022-49784)\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\nmedia: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()\n\nIn dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf\nis null and msg[i].len is zero, former checks on msg[i].buf would be\npassed. Malicious data finally reach dw2102_i2c_transfer. If accessing\nmsg[i].buf[0] without sanity check, null ptr deref would happen.\nWe add check on msg[i].len to prevent crash.\n\nSimilar commit:\ncommit 950e252cb469\n(\u0026quot;[media] dw2102: limit messages to buffer size\u0026quot;)(CVE-2023-53146)\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-SP3","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-265.0.0.167.oe2203sp3"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-debuginfo-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-debugsource-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-devel-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-headers-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-source-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-tools-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-tools-debuginfo-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","kernel-tools-devel-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","perf-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","perf-debuginfo-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","python3-perf-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm","python3-perf-debuginfo-5.10.0-265.0.0.167.oe2203sp3.aarch64.rpm"],"src":["kernel-5.10.0-265.0.0.167.oe2203sp3.src.rpm"],"x86_64":["kernel-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-debuginfo-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-debugsource-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-devel-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-headers-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-source-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-tools-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-tools-debuginfo-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","kernel-tools-devel-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","perf-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","perf-debuginfo-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","python3-perf-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm","python3-perf-debuginfo-5.10.0-265.0.0.167.oe2203sp3.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1570"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-3238"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49784"},{"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-2023-53146"},{"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"}}