GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2025-1570 (CVE-2022-3238)

Vulnerability from osv_openeuler – Published: 2025-05-30 11:08 – Updated: 2026-08-06 11:08 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

A 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)

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling

amd_pmu_enable_all() does:

  if (!test_bit(idx, cpuc->active_mask))
          continue;

  amd_pmu_enable_event(cpuc->events[idx]);

A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables all events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash:

BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK>

amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu.(CVE-2022-49781)

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd/uncore: Fix memory leak for events array

When a CPU comes online, the per-CPU NB and LLC uncore contexts are freed but not the events array within the context structure. This causes a memory leak as identified by the kmemleak detector.

[...] unreferenced object 0xffff8c5944b8e320 (size 32): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8c5944b8dd40 (size 64): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 [...]

Fix the problem by freeing the events array before freeing the uncore context.(CVE-2022-49784)

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix possible refcount leak in smb2_open()

Reference count of acls will leak when memory allocation fails. Fix this by adding the missing posix_acl_release().(CVE-2023-53061)

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd/core: Always clear status for idx

The variable 'status' (which contains the unhandled overflow bits) is not being properly masked in some cases, displaying the following warning:

WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270

This seems to be happening because the loop is being continued before the status bit being unset, in case x86_perf_event_set_period() returns 0. This is also causing an inconsistency because the "handled" counter is incremented, but the status bit is not cleaned.

Move the bit cleaning together above, together when the "handled" counter is incremented.(CVE-2023-53073)

In the Linux kernel, the following vulnerability has been resolved:

media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()

In dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach dw2102_i2c_transfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.

Similar commit: commit 950e252cb469 ("[media] dw2102: limit messages to buffer size")(CVE-2023-53146)

In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply or MST up request sideband message, the drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with the reading/parsing of the message from another thread via drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is possible since the reader/parser doesn't hold any lock while accessing the reception state. This in turn can lead to a memory corruption in the reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST sideband message body length check").

Fix the above by resetting the message reception state if needed before reading/parsing a message. Another solution would be to hold the drm_dp_mst_topology_mgr::lock for the whole duration of the message reception/parsing in drm_dp_mst_handle_down_rep() and drm_dp_mst_handle_up_req(), however this would require a bigger change. Since the fix is also needed for stable, opting for the simpler solution in this patch.(CVE-2024-57876)

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix RCU stall while reaping monitor destination ring

While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id.

However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash.

kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed

Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1(CVE-2024-58097)

In the Linux kernel, the following vulnerability has been resolved:

virtiofs: add filesystem context source name check

In certain scenarios, for example, during fuzz testing, the source name may be NULL, which could lead to a kernel panic. Therefore, an extra check for the source name should be added.(CVE-2025-37773)

In the Linux kernel, the following vulnerability has been resolved:

hfs/hfsplus: fix slab-out-of-bounds in hfs_bnode_read_key

Syzbot reported an issue in hfs subsystem:

BUG: KASAN: slab-out-of-bounds in memcpy_from_page include/linux/highmem.h:423 [inline] BUG: KASAN: slab-out-of-bounds in hfs_bnode_read fs/hfs/bnode.c:35 [inline] BUG: KASAN: slab-out-of-bounds in hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 Write of size 94 at addr ffff8880123cd100 by task syz-executor237/5102

Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 memcpy_from_page include/linux/highmem.h:423 [inline] hfs_bnode_read fs/hfs/bnode.c:35 [inline] hfs_bnode_read_key+0x314/0x450 fs/hfs/bnode.c:70 hfs_brec_insert+0x7f3/0xbd0 fs/hfs/brec.c:159 hfs_cat_create+0x41d/0xa50 fs/hfs/catalog.c:118 hfs_mkdir+0x6c/0xe0 fs/hfs/dir.c:232 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdir fs/namei.c:4300 [inline] __se_sys_mkdir fs/namei.c:4298 [inline] __x64_sys_mkdir+0x6c/0x80 fs/namei.c:4298 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbdd6057a99

Add a check for key length in hfs_bnode_read_key to prevent out-of-bounds memory access. If the key length is invalid, the key buffer is cleared, improving stability and reliability.(CVE-2025-37782)

In the Linux kernel, the following vulnerability has been resolved:

jfs: reject on-disk inodes of an unsupported type

Syzbot has reported the following BUG:

kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 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 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>

This happens when 'clear_inode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.(CVE-2025-37925)

In the Linux kernel, the following vulnerability has been resolved:

ftrace: Add cond_resched() to ftrace_graph_set_hash()

When the kernel contains a large number of functions that can be traced, the loop in ftrace_graph_set_hash() may take a lot of time to execute. This may trigger the softlockup watchdog.

Add cond_resched() within the loop to allow the kernel to remain responsive even when processing a large number of functions.

This matches the cond_resched() that is used in other locations of the code that iterates over all functions that can be traced.(CVE-2025-37940)

In the Linux kernel, the following vulnerability has been resolved:

block: fix resource leak in blk_register_queue() error path

When registering a queue fails after blk_mq_sysfs_register() is successful but the function later encounters an error, we need to clean up the blk_mq_sysfs resources.

Add the missing blk_mq_sysfs_unregister() call in the error path to properly clean up these resources and prevent a memory leak.(CVE-2025-37980)

Severity
8.4 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "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"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-265.0.0.167.oe2203sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\u2019s 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)",
  "id": "OESA-2025-1570",
  "modified": "2026-08-06T11:08:39Z",
  "published": "2025-05-30T11:08:39Z",
  "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"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "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"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.