What is the CVSS score of CVE-2026-72335?

CVE-2026-72335 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.2%.

Which versions of Linux Kernel are affected by CVE-2026-72335?

A Linux kernel Bluetooth vulnerability (CVE-2026-72335) could enable privilege escalation from limited user access to system administrator control, affecting organizations whose infrastructure…. A patch is available.

How to fix or mitigate CVE-2026-72335?

Within 24 hours, identify affected Linux systems by cross-referencing your kernel versions against the vendor advisory for CVE-2026-72335. Within 7 days, apply the available vendor patch to all identified systems, prioritizing production environments. Within 30 days, complete patch deployment verification to ensure no vulnerable instances remain in your infrastructure.

Linux Kernel CVE-2026-72335

EUVD-2026-59234 HIGH

2026-08-15 Linux

GHSA-3hg2-6vgw-gv3f

Information Disclosure Linux Red Hat Suse

7.8

CVSS 3.1 · Vendor: Linux

Severity by source

Vendor (Linux) PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.0 HIGH

Race between async MSFT callback and MGMT work queue justifies AC:H; PR:L for Bluetooth socket access; full kernel UAF impact warrants C/I/A:H.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SUSE

6.4 MEDIUM

AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H

Red Hat

5.5 MEDIUM

qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 17, 2026 - 08:31 vuln.today

CVSS changed

Aug 17, 2026 - 06:22 NVD

7.8 (HIGH)

Patch available

Aug 15, 2026 - 07:20 EUVD

CVE Published

Aug 15, 2026 - 05:55 cve.org

HIGH 7.8

CVE Published

Aug 15, 2026 - 05:55 cve.org

UNKNOWN (no severity yet)

DescriptionCVE.org

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

Bluetooth: MGMT: Fix adv monitor add failure cleanup

hci_add_adv_monitor() publishes a new adv_monitor in hdev->adv_monitors_idr before the powered MSFT setup step. The MSFT offload add path can then fail either locally before the controller add command completes, or in the MSFT add callback. In the current queued management add flow, hci_cmd_sync_work() still invokes mgmt_add_adv_patterns_monitor_complete() with the original pending command after msft_add_monitor_pattern() returns.

The buggy scenario involves two paths, with each column showing the order within that path:

MSFT add handling MGMT completion

insert monitor and handle 1. receive sync error
send MSFT add command 2. call add-monitor completion
callback sees bad response 3. load cmd->user_data
callback frees monitor 4. read monitor->handle

Local MSFT setup failures have the other half of the same ownership bug: they return an error after the IDR insertion, but no later code removes the failed monitor from the IDR.

Keep ownership with the pending management command until its completion. For normal management adds, the MSFT add callback now records successful controller state and returns errors to its caller. The management completion frees the monitor on non-success after copying the response handle, while resume/reregister callback-error cleanup remains in the MSFT callback. The success path keeps the existing bookkeeping.

Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth]

Call Trace: <TASK> dump_stack_lvl+0x66/0xa0 print_report+0xce/0x5f0 ? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] ? srso_alias_return_thunk+0x5/0xfbef5 ? __virt_addr_valid+0x19f/0x330 ? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] kasan_report+0xe0/0x110 ? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth] ? srso_alias_return_thunk+0x5/0xfbef5 ? 0xffffffffc00d00da ? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth] ? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth] ? hci_cmd_sync_work+0x1ab/0x210 [bluetooth] hci_cmd_sync_work+0x1c0/0x210 [bluetooth] ? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth] process_one_work+0x4fd/0xbc0 ? __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_hci_cmd_sync_work+0x10/0x10 [bluetooth] ? 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>

Allocated by task 471 on cpu 3 at 285.205389s: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 __kasan_kmalloc+0xaa/0xb0 add_adv_patterns_monitor_rssi+0xd5/0x230 [bluetooth] hci_sock_sendmsg+0x96b/0xf80 [bluetooth] __sys_sendto+0x2bc/0x2d0 __x64_sys_sendto+0x76/0x90 do_syscall_64+0x115/0x6a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 454 on cpu 2 at 285.217112s: kasan_save_stack+0x33/0x60 kasan_save_track+0x17/0x60 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x5f/0x80 kfree+0x313/0x590 msft_add_monitor_sync+0x54a/0x570 [bluetooth] hci_add_adv_monitor+0x133/0x180 [bluetooth] hci_cmd_sync_work+0x187/0x210 [bluetooth] process_one_work+0x4fd/0xbc0 worker_thread+0x2d8/0x570 kthread+0x1ad/0x1f0 ret_from_fork+0x3c9/0x540 ret_from_fork_asm+0x1a/0x30

AnalysisAI

Use-after-free in the Linux kernel Bluetooth MGMT advertising monitor subsystem allows a local attacker with low privileges to corrupt kernel heap memory, potentially achieving privilege escalation. The flaw arises from a ownership race: hci_add_adv_monitor() publishes a new adv_monitor into the hdev->adv_monitors_idr before the MSFT HCI offload setup step completes, allowing the MSFT callback to free the monitor on failure while the MGMT completion path still holds a dangling pointer. KASAN confirmed the slab-use-after-free in mgmt_add_adv_patterns_monitor_complete; no public exploit or active exploitation (CISA KEV) has been identified, and EPSS is 0.21% (12th percentile).

Technical ContextAI

The vulnerable code resides in the Linux kernel Bluetooth stack's MGMT (Management) interface and MSFT HCI extension layer, which provides controller-offload for Bluetooth advertising monitor patterns. The root cause is a CWE-416 (Use After Free): hci_add_adv_monitor() inserts a newly allocated adv_monitor struct into the IDR (idr data structure for ID allocation) before the asynchronous MSFT controller setup completes. Two failure paths both exhibit the ownership bug: the MSFT add callback can free the monitor on a bad controller response while hci_cmd_sync_work() subsequently invokes mgmt_add_adv_patterns_monitor_complete() with a stale user_data pointer to the now-freed struct; and local MSFT setup failures return an error after IDR insertion without removing the failed entry. CPE cpe:2.3:a:linux:linux:* confirms the Linux kernel across all platforms, but practical exposure requires a Bluetooth controller with MSFT HCI extension support.

RemediationAI

Upgrade the Linux kernel to one of the patched stable releases: 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5, or apply the 7.2-rc3 patch set. Fix commits are available at https://git.kernel.org/stable/c/b1a719b3c4359ef731646fb7c7844e53dddbda72, https://git.kernel.org/stable/c/5aabbd01ac315a72bcdfd42985ede712c4744689, https://git.kernel.org/stable/c/dfc8373893b1876bb367700eac9d776316dabd96, https://git.kernel.org/stable/c/dbd935a9e056545721bc4e9ce518c775d787b21e, https://git.kernel.org/stable/c/384a4b2fef9ffe5e270ee5558975c0504881c5fb, and https://git.kernel.org/stable/c/fb256d07395ebbc950f42e439d3896ec3a25c845. Distribution-specific backports should be applied via vendor update channels (RHEL, Ubuntu, SUSE, Debian). As a compensating control on systems that cannot be patched immediately, disabling or restricting access to the Bluetooth HCI socket (e.g., removing users from the bluetooth group, setting restrictive udev rules on /dev/hci* devices, or unloading the bluetooth and btusb kernel modules) prevents exploitation but also disables Bluetooth functionality entirely. Restricting CAP_NET_ADMIN to trusted users limits the privilege surface but does not fully mitigate the flaw on systems with permissive Bluetooth socket access.

Same technique Information Disclosure

View all

CVE-2019-2725 CRITICAL POC

9.8

CVE-2021-34523 CRITICAL POC

9.0

CVE-2013-2251 CRITICAL POC

9.8

CVE-2017-5638 CRITICAL POC

9.8

CVE-2025-24813 CRITICAL POC

9.8

CVE-2015-1701 HIGH POC

7.8

CVE-2017-0147 HIGH POC

7.5

CVE-2014-6324 HIGH POC

8.8

Vendor StatusVendor

SUSE

Severity: Moderate

Product	Status
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0	Not-Affected

CVE-2026-72335 vulnerability details – vuln.today

Back

Linux Kernel CVE-2026-72335

Severity by source

CVSS VectorVendor: Linux

Lifecycle Timeline

DescriptionCVE.org

AnalysisAI

Technical ContextAI

RemediationAI

Same technique Information Disclosure

Vendor StatusVendor

SUSE

Share

External POC / Exploit Code