OnlyPatch
Windows Bluetooth Port Driver

CVE-2026-45640 — Windows Bluetooth Port Driver Elevation of Privilege Vulnerability

Important CVSS 7 EPSS 0.00234 🔬 Patch diffed 2026-06 archive

Executive Summary

Use after free in Windows Bluetooth Port Driver allows an authorized attacker to elevate privileges locally.

Overview

7
CVSS HIGH
Important
MS Severity
Not Exploited
MS Exploit Status
Less Likely
MS Exploit Likelihood
Category Elevation of Privilege
Weakness CWE-416: Use After Free
Released Jun 9 2026
Last Updated Jun 9 2026
Publicly Disclosed No
CISA KEV Not Listed
Known Exploits None Known
EPSS Score 0.00234 — 0.14389 percentile
NVD CVSS 7 HIGH — matches MSRC

CVSS Vector

CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
ATTACK VECTOR
Local
ATTACK COMPLEXITY
High
PRIVILEGES REQUIRED
Low
USER INTERACTION
None
SCOPE
Unchanged
CONFIDENTIALITY
High
INTEGRITY
High
AVAILABILITY
High
EXPLOIT CODE MATURITY
Unproven
REMEDIATION LEVEL
Official Fix
REPORT CONFIDENCE
Confirmed
Temporal Score: 6.1

EPSS Score

0.00234
probability of exploitation in the next 30 days
0.14389 percentile - updated 2026-08-14
View on FIRST.org

Affected Products

18 affected products
Product KB Article Severity Impact Restart Required
Windows 10 Version 21H2 for 32-bit Systems 5094127 (Security Update) Important Elevation of Privilege Yes
Windows 10 Version 21H2 for ARM64-based Systems 5094127 (Security Update) Important Elevation of Privilege Yes
Windows 10 Version 21H2 for x64-based Systems 5094127 (Security Update) Important Elevation of Privilege Yes
Windows 10 Version 22H2 for 32-bit Systems 5094127 (Security Update) Important Elevation of Privilege Yes
Windows 10 Version 22H2 for ARM64-based Systems 5094127 (Security Update) Important Elevation of Privilege Yes
Windows 10 Version 22H2 for x64-based Systems 5094127 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 23H2 for ARM64-based Systems 5093998 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 23H2 for x64-based Systems 5093998 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 24H2 for ARM64-based Systems 5094126 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 24H2 for x64-based Systems 5094126 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 25H2 for ARM64-based Systems 5094126 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 25H2 for x64-based Systems 5094126 (Security Update) Important Elevation of Privilege Yes
Windows 11 Version 26H1 for ARM64-based Systems 5095051 (Security Update) Important Elevation of Privilege Yes
Windows 11 version 26H1 for x64-based Systems 5095051 (Security Update) Important Elevation of Privilege Yes
Windows Server 2022 5094128 (Security Update) Important Elevation of Privilege Yes
Windows Server 2022 (Server Core installation) 5094128 (Security Update) Important Elevation of Privilege Yes
Windows Server 2025 5094125 (Security Update) Important Elevation of Privilege Yes
Windows Server 2025 (Server Core installation) 5094125 (Security Update) Important Elevation of Privilege Yes

Patches

6 patches
Article Type Restart
5094127 Security Update Yes
5093998 Security Update Yes
5094126 Security Update Yes
5095051 Security Update Yes
5094128 Security Update Yes
5094125 Security Update Yes

Patch Diff

ghidriff · bthport.sys (KB5094126)

Use-after-free / double-free race (CWE-416) in the Windows Bluetooth port driver bthport.sys, local EoP. HciLELegacyAdvertisingRequestCoordinator::MarkAllAdvertisingRequestAsNew iterates pending LE legacy advertising requests and re-sets each IRP's cancellation routine (ClearRequestCancellationRoutine then SetRequestCancellationRoutine). ClearRequestCancellationRoutine fails when the IRP's cancellation is already in progress (the cancel callback is already completing/freeing that IRP). PRE: on a Clear failure the code fell through to LAB_0 and set the per-request error flag (*(lVar1+8) |= 4), marking the IRP as MarkAll's own cleanup/error-handling target even though the cancel callback owns it - so a single IRP could be completed and freed on two paths at once (double free / UAF). IN-HOUSE ghidriff of bthport.sys 10.0.26100.8524 -> .8655 (Jun 9 2026, KB5094126) confirms the fix: MarkAllAdvertisingRequestAsNew is the only code-changed function; gated behind CFR flag Feature_697033018, a Clear failure now sets no error flag and exits (the cancel callback alone owns the IRP), and only the Clear-succeeded-but-Set-failed case sets the error flag for genuine cleanup. Removes the race between the cancellation callback and MarkAll. Note: our x64 24H2 diff shows flag Feature_697033018, differing from the circulated screenshots' Feature_965468474 (build/arch difference); we ship what our diff shows.

Pre-patch version 10.0.26100.8524 Download
Post-patch version 10.0.26100.8655 Download
Function Address Change Note
HciLELegacyAdvertisingRequestCoordinator::MarkAllAdvertisingRequestAsNew code change code (stop error-flagging IRPs whose cancellation is in progress, CFR-gated) Pre: `ClearRequestCancellationRoutine` fail -> LAB_0 -> `*(lVar1+8) |= 4` (error flag) -> IRP marked for MarkAll cleanup while the cancel callback also frees it -> double free/UAF. Post (Feature_697033018 enabled): Clear-fail sets no flag and exits (callback owns the IRP); only Clear-OK + Set-fail sets `| 4`. The in-progress flag `| 1` and the operation_guard acquire around the section are unchanged.
Feature_697033018 new flag added (CFR gate) New Controlled Feature Rollout flag introduced by this patch (Feature_697033018__private_IsEnabledDeviceUsageNoInline / _IsEnabledFallback) gating the fixed handling; the original racy path (iVar4==0) still ships in .8655.
View full diff report View RCA report

Attack Path

MarkAllAdvertisingRequestAsNew error-flags an IRP whose cancellation is already in flight, so both paths free it

Attack path for CVE-2026-45640 MarkAllAdvertisingRequestAsNew error-flags an IRP whose cancellation is already in flight, so both paths free it 01 — ENTRY Local low-priv process drives LE advertising register/cancel churn bthport.sys (kernel) manages pending LE legacy advertising IRPs. A local caller can force many requests and race their cancellation - AC:H reflects the timing window. 02 — CONTROLLED INPUT An advertising IRP's cancellation is already in progress The I/O manager has invoked the request's cancellation callback, which will complete and free that IRP. 03 — PATH MarkAllAdvertisingRequestAsNew re-sets each request's cancellation routine It calls ClearRequestCancellationRoutine then SetRequestCancellationRoutine on each pending IRP. Clear FAILS for the IRP whose cancellation is already in progress. 04 — MISSING CHECK On Clear-failure it still sets the error flag (| 4), claiming the IRP for cleanup Pre-patch, a Clear failure falls to LAB_0 and sets *(req+8) |= 4, so MarkAll treats the in-flight IRP as its own error-handling/cleanup target (CWE-416). 05 — PRIMITIVE Same IRP completed & freed on two paths -> double free / UAF -> EoP The cancellation callback and MarkAll both free the one IRP, corrupting kernel pool for elevation. The Jun 2026 fix (Feature_697033018) makes Clear-fail set no flag and exit, leaving the callback as sole owner.

Derived from the patch delta: the checks added by the vendor identify which fields crossed a trust boundary unvalidated. Reachability and privilege are taken from the call chain in the RCA report.

Known Exploits

Acknowledgments

hazard

On This Page