CVE-2025-38117: Linux Kernel Security (CVSS 7.8 HIGH)

TL;DR and CVE Summary

What This Vulnerability Actually Is

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Protect mgmt_pending list with its own lock This uses a mutex to protect from concurrent access of mgmt_pending list which can cause crashes like: ================================================================== BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318 CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline ---truncated---

The CVSS 3.1 vector decomposes as follows: Local attack vector. low complexity. low privileges required. no user interaction. scope unchanged. high confidentiality impact. high integrity impact. high availability impact. The primary weakness classification is CWE-416 (Security). The vulnerability arises from insufficient input validation or improper trust-boundary handling in the affected component. The exact technical mechanism depends on the specific code path involved (see vendor advisory for source-level detail).

For investigators and defenders the practical translation of the CVSS vector matters. Network attack vectors mean the exposure surface is reachable from outside the affected host. Local vectors mean the attacker needs prior local access. Adjacent network vectors mean network-adjacent access (same VLAN or subnet) is required. The privileges-required field tells the defender whether an authenticated foothold is needed; no-privileges-required vulnerabilities can be exploited by unauthenticated traffic which expands the attack surface meaningfully. The user-interaction field is the other major control lever: vulnerabilities requiring user interaction typically depend on phishing or drive-by delivery paths that additional email and web-filtering controls can mitigate. Scope-changed vulnerabilities are the class defenders should treat as highest priority because exploitation crosses a security boundary the affected component was supposed to enforce; a compromised authentication scope often means credential extraction against the entire tenant and lateral movement into related systems.

How an Attacker Would Exploit This

Attackers exploiting this class of vulnerability typically begin with reconnaissance to confirm the affected component is reachable and running a vulnerable version. The attack chain then follows the CVSS attack-vector path: for network-vector vulnerabilities the attacker probes the exposed interface; for adjacent-network vulnerabilities the attacker positions on the relevant network segment; for local vulnerabilities the attacker already has local access and exploits the vulnerability for privilege escalation. The exact exploitation steps depend on the affected component and any publicly-available proof-of-concept code.

This explanation is provided for defensive context. Sherlock Forensics does not publish weaponized proof-of-concept code. The exploitation path explanation is what defenders need to design detection rules and understand the attack surface; the precise weaponized payload belongs in vendor-coordinated disclosure and security research channels not in public-facing forensic analysis content. Where public exploit code does exist in the inventories below, defenders can review it through the linked sources for completeness.

The reconnaissance phase that typically precedes exploitation is worth understanding separately. Attackers scanning for the affected component typically fingerprint the version banner over standard protocols (HTTP for web-tier vulnerabilities, SSH and Telnet for management-plane vulnerabilities, service-specific banners for application-tier vulnerabilities). Modern attacker tooling (Shodan queries, Censys scans, mass port scanning with Zmap or Masscan) inventories every reachable instance of the affected component before targeting any specific host. For defenders the reconnaissance phase is the first opportunity for detection: unusual scanning against the exposed component surface and version-fingerprint probes leaves logging traces on the network perimeter and in the affected application access logs. Detecting reconnaissance early buys the defender the window needed to patch or apply compensating controls before the mass-exploitation phase begins.

Public Exploit Availability

CISA Known Exploited Vulnerabilities catalog: NOT listed as of the publication date of this article. CISA KEV listing requires evidence of active exploitation in the wild and federal-agency patching mandate. Absence from KEV does not mean absence of exploitation; it means CISA has not yet observed enough exploitation evidence to add the CVE to the catalog.

ExploitDB: No public exploit code identified in the ExploitDB catalog as of the publication date of this article.

GitHub: No top-starred public proof-of-concept repositories identified referencing this CVE as of the publication date of this article.

Metasploit Framework: No exploit or auxiliary module identified in the Rapid7 metasploit-framework repository as of the publication date of this article.

Nuclei templates: No detection template identified in the ProjectDiscovery nuclei-templates repository as of the publication date of this article.

The exploit-availability inventory above represents a snapshot at the publication date of this article. Public exploit availability changes over time. New ExploitDB entries and new GitHub PoC repositories and new Metasploit modules and new Nuclei templates may appear in the weeks after disclosure. Defenders should re-check the inventory periodically through the cited sources to stay current.

Forensic Detection Angle

For a forensic investigator or incident responder approaching a system suspected of exploitation by CVE-2025-38117 the detection workflow begins with the affected component access logs. For network-attack-vector vulnerabilities the relevant logs are web server access logs and application logs that capture the inbound request and the application response. For local-attack-vector vulnerabilities the relevant logs are system event logs (Windows Security and Windows Application and Sysmon when present; Linux auth.log and journald) and process execution evidence (Windows ShimCache and AmCache; Linux audit framework).

The detection pattern for Security vulnerabilities typically shows in log artifacts as anomalous input and anomalous response correlation. The Sigma signature in the next section provides a starting detection logic; investigators should tune the signature to the specific affected component and the local log infrastructure. For organizations running endpoint detection and response (EDR) tooling the equivalent rule definitions in the EDR-specific query language (Microsoft Defender for Endpoint advanced hunting, CrowdStrike Falcon, SentinelOne, Sophos) cover the same logic and integrate into the existing security operations workflow.

Log retention is the practical constraint that most investigations run into after the fact. Web server access logs at default settings often retain only 30 to 90 days of history. Application logs vary widely; some retain days, others retain years. Windows Security event logs are size-bounded and can roll over within hours on busy systems. Linux systemd-journald retention is size-bounded and configuration-dependent. For any investigation the acquisition timing matters: preserve the relevant logs immediately upon suspicion because normal operation continues to roll the retention window forward. The Sherlock Forensics methodology treats log acquisition as an early-triage priority in every incident response engagement and documents the artifact retention window as part of the acquisition record. For organizations building incident response capacity the operational discipline is to extend retention on critical log sources beyond default settings and to include log destination inventory as part of the standard IR playbook so the acquisition team knows where every relevant log lives before an incident begins.

Detection Signature

The following Sigma rule covers the Security pattern as it commonly appears in web server logs. Adapt the logsource and the field names to your specific stack. For non-web-application vulnerabilities the same logic translates to the corresponding application-tier log shape.

title: Generic Vulnerability Exploitation Indicators
id: cve-2025-38117-sigma-rule
status: experimental
description: Generic detection signature for the vulnerability class. Tune to the specific affected component.
references:
  - vendor advisory
logsource:
  product: webserver
  category: webserver
detection:
  selection_anomaly:
    sc-status:
      - 500
      - 502
      - 503
  condition: selection_anomaly
falsepositives:
  - Routine application errors
level: low

The signature is starting logic. Production deployment requires tuning to reduce false positives against the specific application context. The signature is most effective when combined with other detection layers (network signature, application-specific WAF rules, EDR behavior rules).

Mitigation and Patch Guidance

The vendor remediation path for CVE-2025-38117 is published in the vendor advisory linked in the references section. Apply the vendor patch through the normal change management process. For organizations that cannot apply the patch within the standard SLA the compensating controls depend on the CVSS vector: for network-vector vulnerabilities the compensating controls include access restriction at the perimeter and WAF signatures and network segmentation; for local-vector vulnerabilities the compensating controls include privilege restriction and binary allowlisting.

After patch deployment the verification step confirms the affected version has been replaced with the fixed version. The verification command varies by component: package manager queries (rpm -qa and dpkg -l on Linux; Get-Package on Windows) confirm OS-package versions; application-specific version checks (Get-Module and Get-Item Version for Windows applications; npm ls and pip show for language ecosystems) confirm application-tier versions. For network-exposed services a direct probe of the version banner can confirm the patched version is in production. Document the verification result as part of the remediation record.

Post-patch monitoring matters as much as the patch itself. The Sigma signature provided above should be deployed even after the patch is applied because exploitation attempts continue against systems regardless of patched state. Failed exploitation attempts in the post-patch log stream are themselves intelligence about the threat landscape facing the affected component. Sherlock Forensics engagements routinely include post-remediation monitoring as part of the broader incident response and prevention scope.

References and Further Reading

• NIST National Vulnerability Database entry for CVE-2025-38117
• Vendor advisory
• https://git.kernel.org/stable/c/6fe26f694c824b8a4dbf50c635bee1302e3f099c
• https://git.kernel.org/stable/c/7b5958332f20dc66b19be564c402dbc21b927a81
• https://git.kernel.org/stable/c/bdd56875c6926d8009914f427df71797693e90d4
• https://git.kernel.org/stable/c/d7882db79135c829a922daf3571f33ea1e056ae3

For Canadian organizations operating under PIPEDA or provincial-equivalent privacy frameworks an incident that involves exploitation of CVE-2025-38117 may carry breach notification obligations depending on the data exposure. The Sherlock PIPEDA Section 4.7 Compliance Deep Dive covers the notification framework. For incident response engagement support on this CVE class the Sherlock services page documents the methodology Sherlock applies to investigations involving the affected component class.