CVE-2025-37947

Published May 20, 2025

Last updated 2 months ago

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-37947 is a vulnerability found in the Linux kernel's ksmbd filesystem component, specifically within the `ksmbdvfsstream_write()` function. Disclosed on May 20, 2025, the vulnerability arises from a missing bounds check in the `ksmbdvfsstreamwrite()` function. The function doesn't validate if the write offset (`*pos`) is within the bounds of the existing stream data length (`vlen`). If `*pos` is greater than or equal to `v_len`, it can lead to an out-of-bounds memory write. Successful exploitation of this vulnerability could result in out-of-bounds memory writes in the Linux kernel, potentially causing memory corruption or system crashes. A patch has been implemented to address this issue by adding a validation check for the write offset in `ksmbdvfsstreamwrite()`. The fix ensures that `*pos` is less than `vlen` before proceeding with the write operation, returning `-EINVAL` if the condition fails.

Description
In the Linux kernel, the following vulnerability has been resolved: ksmbd: prevent out-of-bounds stream writes by validating *pos ksmbd_vfs_stream_write() did not validate whether the write offset (*pos) was within the bounds of the existing stream data length (v_len). If *pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write. This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.
Source
416baaa9-dc9f-4396-8d5f-8c081fb06d67
NVD status
Modified
Products
linux_kernel, debian_linux

Risk scores

CVSS 3.1

Type
Primary
Base score
7.8
Impact score
5.9
Exploitability score
1.8
Vector string
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

Weaknesses

nvd@nist.gov
CWE-787
134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-787

Social media

Hype score
Not currently trending
  1. ksmbd - Exploiting CVE-2025-37947 (3/3) #CVE202537947 #ksmbd #OOBWrite #PrivilegeEscalation #LinuxKernel https://t.co/E4fuSaYTiu

    @reverseame

    2 Feb 2026

    1000 Impressions

    4 Retweets

    7 Likes

    4 Bookmarks

    0 Replies

    0 Quotes

  2. ksmbd - Exploiting CVE-2025-37947 (3/3) · Doyensec's Blog https://t.co/22HDfC4fjv

    @Komodosec

    17 Nov 2025

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. Top 5 Trending CVEs: 1 - CVE-2021-28550 2 - CVE-2025-33073 3 - CVE-2023-20870 4 - CVE-2025-37947 5 - CVE-2025-22131 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    26 Oct 2025

    11 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. ksmbd - Exploiting CVE-2025-37947 Article by @73696e65 about locally exploiting CVE-2025-37947 — a page OOB write in the ksmbd module. Article: https://t.co/V5LBTtOqxY Exploit: https://t.co/knpaTnIO2j https://t.co/jADk5UqFEn

    @linkersec

    24 Oct 2025

    12092 Impressions

    44 Retweets

    184 Likes

    58 Bookmarks

    0 Replies

    2 Quotes

  5. Linux kernel ksmbd モジュールの脆弱性 CVE-2025-37947:ローカル権限昇格と PoC の公開 https://t.co/02xnThNPhy この脆弱性の原因は、ksmbd_vfs_stream_write() における拡張属性 (xattr) 書き込みのサイズ検証不備にあります。割当

    @iototsecnews

    20 Oct 2025

    96 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. Exploiting CVE-2025-37947 (Linux kernel's ksmbd) https://t.co/3l5LuiehvQ

    @Karma_X_Inc

    19 Oct 2025

    74 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. ksmbd - Exploiting CVE-2025-37947 (3/3) https://t.co/J3XQM6nK4L

    @ytroncal

    12 Oct 2025

    43 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  8. CVE-2025-37947 : Linux kernel's ksmbd LPE Exploiting https://t.co/9BOFXgcoNH https://t.co/Sfw9mCfMrS

    @freedomhack101

    9 Oct 2025

    81 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  9. #exploit #Kernel_Security Ksmbd Vulnerability Research Part 1 - CVE-2024-50283, CVE-2024-50285, CVE-2024-50286 - https://t.co/zoZsNbjEJK Part 2 - Fuzzing Improvements and Vulnerability Discovery - https://t.co/t1xCLqun8C Part 3 - Exploiting CVE-2025-37947 -

    @ksg93rd

    9 Oct 2025

    2937 Impressions

    10 Retweets

    50 Likes

    23 Bookmarks

    0 Replies

    0 Quotes

  10. csirt_it: ‼ #Linux: disponibile un #PoC per lo sfruttamento combinato della CVE-2025-37947 che interessa relative al modulo #KSMBD Rischio: 🟠 Tipologia: 🔸 Privilege Escalation 🔗 https://t.co/uEP8YyGW7C ⚠ Importante mantenere aggiornati i… https://t.co/A

    @Vulcanux_

    9 Oct 2025

    53 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. 🔥 Alerta crítico para admins Linux! Uma vulnerabilidade de alta gravidade (CVE-2025-37947) no ksmbd do kernel Linux permite escalada de privilégios para acesso root. Seus sistemas estão em risco! 🚨 Atualize suas distros AGORA. #Linux #CyberSecurity #CVE https://t.co/8Qt

    @fernandokarl

    9 Oct 2025

    42 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. ksmbd - Exploiting CVE-2025-37947 (3/3) https://t.co/AvRjgQT32z https://t.co/dKxpvu7YiR

    @Tinolle1955

    8 Oct 2025

    35 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  13. ksmbd - Exploiting CVE-2025-37947 (3/3) https://t.co/7I0RV6RcYh

    @Dinosn

    8 Oct 2025

    929 Impressions

    0 Retweets

    1 Like

    3 Bookmarks

    0 Replies

    0 Quotes

Configurations

  1. In the Linux kernel, the following vulnerability has been resolved: usb: misc: usbio: fix disconnect UAF in client teardown usbio_disconnect() walks usbio->cli_list in reverse and uninitializes each auxiliary device. auxiliary_device_uninit() drops the device reference, and for an unbound child that can run usbio_auxdev_release() and free the containing struct usbio_client. list_for_each_entry_reverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliary_device_uninit(), the iterator dereferences freed memory. Use list_for_each_entry_safe_reverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbio_disconnect+0x12e/0x150 Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x630 ? usbio_disconnect+0x12e/0x150 ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x188/0x320 ? usbio_disconnect+0x12e/0x150 kasan_report+0xe0/0x110 ? usbio_disconnect+0x12e/0x150 usbio_disconnect+0x12e/0x150 usb_unbind_interface+0xf3/0x400 really_probe+0x316/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? _raw_spin_unlock_irqrestore+0x44/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? lockdep_hardirqs_on_prepare+0xea/0x1a0 ? srso_alias_return_thunk+0x5/0xfbef5 ? usb_enable_lpm+0x3c/0x260 usb_set_configuration+0xb64/0xf20 usb_generic_driver_probe+0x5f/0x90 usb_probe_device+0x71/0x1b0 really_probe+0x46b/0x660 __driver_probe_device+0x106/0x240 driver_probe_device+0x4a/0x110 __device_attach_driver+0xf1/0x1a0 ? __pfx___device_attach_driver+0x10/0x10 bus_for_each_drv+0xf9/0x160 ? __pfx_bus_for_each_drv+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? trace_hardirqs_on+0x18/0x130 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __device_attach+0x133/0x2a0 ? __pfx___device_attach+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_raw_spin_unlock+0x9a/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 device_initial_probe+0x55/0x70 bus_probe_device+0x4a/0xd0 device_add+0x9b9/0xc10 ? __pfx_device_add+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? add_device_randomness+0xb7/0xf0 usb_new_device+0x492/0x870 hub_event+0x1b10/0x29c0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_acquire+0x187/0x300 ? process_one_work+0x475/0xb90 ? srso_alias_return_thunk+0x5/0xfbef5 ? lock_release+0xc8/0x290 ? srso_alias_return_thunk+0x5/0xfbef5 process_one_work+0x4d7/0xb90 ? __pfx_process_one_work+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __list_add_valid_or_report+0x37/0xf0 ? __pfx_hub_event+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 worker_thread+0x2d8/0x570 ? __pfx_worker_thread+0x10/0x10 kthread+0x1ad/0x1f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x3c9/0x540 ? __pfx_ret_from_fork+0x10/0x10 ? srso_alias_return_thunk+0x5/0xfbef5 ? __switch_to+0x2e9/0x730 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>CVE-2026-64453
  2. In the Linux kernel, the following vulnerability has been resolved: tracing: Fix NULL pointer dereference in func_set_flag() func_set_flag() dereferences tr->current_trace_flags before verifying that the current tracer is actually the function tracer. When the active tracer has been switched away from "function" (e.g., to "wakeup_rt"), tr->current_trace_flags can be NULL, leading to a NULL pointer dereference and kernel crash. The call chain that triggers this is: trace_options_write() -> __set_tracer_option() -> trace->set_flag() /* func_set_flag */ In func_set_flag(), the first operation is: if (!!set == !!(tr->current_trace_flags->val & bit)) This dereferences tr->current_trace_flags unconditionally. The safety check that guards against a non-function tracer: if (tr->current_trace != &function_trace) return 0; is placed *after* the dereference, which is too late. This was observed with the following crash dump: BUG: unable to handle page fault at 0000000000000000 RIP: func_set_flag+0xd Call Trace: __set_tracer_option+0x27 trace_options_write+0x75 vfs_write+0x12a ksys_write+0x66 do_syscall_64+0x5b RIP: ffffffff914c973d RSP: ff67ec88b01dfdf0 RFLAGS: 00010202 RAX: 0000000000000000 RBX: ff3a826e80354580 RCX: 0000000000000001 RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff93918080 The disassembly confirms the fault: func_set_flag+0: mov 0x1f08(%rdi), %rax ; RAX = tr->current_trace_flags = NULL func_set_flag+13: mov (%rax), %eax ; page fault: dereference NULL At the time of the crash: tr->current_trace_flags = 0x0 (NULL) tr->current_trace = wakeup_rt_tracer (not function_trace) The scenario is that a process opens a function tracer option file (such as "func_stack_trace"), then the current tracer is switched to another tracer (e.g., "wakeup_rt"), which sets current_trace_flags to NULL. When the process subsequently writes to the option file, func_set_flag() is invoked and crashes on the NULL dereference. Fix this by moving the current_trace check before the current_trace_flags dereference, so that func_set_flag() returns early when the function tracer is not active.CVE-2026-64451
  3. In the Linux kernel, the following vulnerability has been resolved: tipc: fix out-of-bounds read in broadcast Gap ACK blocks A broadcast PROTOCOL/STATE_MSG can carry a Gap ACK blocks record in its data area. tipc_get_gap_ack_blks() only verifies that the record's len field is self-consistent with its ugack_cnt/bgack_cnt counts (sz == struct_size(p, gacks, ugack_cnt + bgack_cnt)); it does not check that the record actually fits in the message data area, msg_data_sz(). The unicast caller tipc_link_proto_rcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipc_bcast_sync_rcv() discards the returned size, so tipc_link_advance_transmq() copies the record off the receive skb with an attacker-controlled count: this_ga = kmemdup(ga, struct_size(ga, gacks, ga->bgack_cnt), GFP_ATOMIC); A TIPC neighbour that negotiated TIPC_GAP_ACK_BLOCK triggers it with one ordinary broadcast STATE_MSG (msg_bc_ack_invalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgack_cnt = 0xff and ugack_cnt = 0. len then equals struct_size(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads struct_size(ga, gacks, 255) = 1024 bytes out of the much smaller skb: BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdup_noprof+0x48/0x60 tipc_link_advance_transmq+0x86c/0xb80 tipc_link_bc_ack_rcv+0x19c/0x1e0 tipc_bcast_sync_rcv+0x1c4/0x2c4 tipc_rcv+0x85c/0x1340 tipc_l2_rcv_msg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuff_small_head of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0) The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used. The unicast STATE path drops such a message: "if (glen > dlen) break;" skips the rest of STATE_MSG handling and the skb is freed. Make the broadcast path drop it too. tipc_bcast_sync_rcv() now bounds the record against msg_data_sz() and, when it does not fit, reports it back through tipc_node_bc_sync_rcv() to tipc_rcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means "legacy peer without Selective ACK", a distinct legitimate state.CVE-2026-64450