CVE-2026-43017

What it actually does

This is a local Linux kernel Bluetooth management input-validation flaw in the mesh advertising send path. The vulnerable code validates the overall MGMT_OP_MESH_SEND command length but does not verify that the embedded adv_data_len field matches the actual flexible adv_data[] bytes supplied by the caller. A truncated management command can therefore be accepted and queued, after which the asynchronous mesh send path may read past the end of the queued command buffer. Based on the assigned CVSS vector, the expected impact is local denial of service through kernel crash, fault, or instability; confidentiality and integrity impact are not indicated.

Why it matters to the business

An attacker with local low-privileged access and the ability to interact with the Bluetooth management interface could crash or destabilize affected Linux systems. The operational risk is highest for workstations, laptops, edge devices, embedded systems, kiosks, and IoT/OT-style Linux devices where Bluetooth is enabled and availability matters. The current EPSS is very low, there is no known CISA KEV listing, no ransomware association, and no reported mature public exploit, so this should generally be treated as a routine kernel hardening and availability fix rather than an emergency internet-facing exposure.

How an attack unfolds

An attacker first obtains local execution on an affected Linux system and access to the Bluetooth management interface, typically requiring some local privilege or capability depending on distribution and configuration. The attacker crafts a Bluetooth management MGMT_OP_MESH_SEND command where the fixed header and total command length pass the existing range checks, but the embedded adv_data_len value does not match the actual bytes present in the flexible adv_data[] field. The vulnerable kernel queues the malformed request because it validates only the broad command length and not the exact flexible-array size. When the asynchronous mesh advertising send path later processes the queued buffer, it can access data beyond the end of that buffer. The likely result is a kernel fault, panic, or other availability-impacting instability. There is no indication from the provided data that this enables remote exploitation, privilege escalation, data theft, or code execution.

How to fix it

Upgrade to a Linux kernel build from the relevant distribution, appliance vendor, or upstream-stable branch that includes the Bluetooth MGMT mesh send advertising payload length validation fix. Because no exact fixed package versions were provided, use vendor advisories and kernel changelogs to confirm inclusion of the patch described as validating mesh send advertising payload length for MGMT_OP_MESH_SEND. Where immediate patching is not possible, reduce exposure by disabling Bluetooth if it is not required, unloading or blacklisting Bluetooth modules where operationally safe, disabling Bluetooth services on servers and appliances that do not need them, and restricting local users, containers, and services from receiving capabilities such as CAP_NET_ADMIN or other permissions that allow interaction with Bluetooth management sockets. Mitigations should be validated carefully on systems that rely on Bluetooth, BLE, mesh networking, keyboards, headsets, medical peripherals, industrial sensors, or embedded radio functions.

How to confirm the fix worked

Confirm the running kernel version is supplied by a vendor build that contains the fix, not merely that a package is installed on disk. Review distribution kernel changelogs, security advisories, or backport notes for wording similar to validating MGMT_OP_MESH_SEND adv_data_len against the exact command length. Verify whether Bluetooth is enabled by checking loaded Bluetooth modules, active Bluetooth services, and hardware presence; systems without Bluetooth support or with Bluetooth disabled have significantly reduced practical exposure. In a controlled non-production environment, validation can include sending malformed mesh send management requests and confirming they are rejected rather than queued or causing a kernel fault. After remediation, monitor for absence of new kernel oops, panic, or Bluetooth management crash events during normal Bluetooth use.

Typical attack path

1. Gain local execution on an affected Linux system.
2. Obtain the ability to open or interact with the Bluetooth management control interface, subject to local permissions and capabilities.
3. Craft a malformed MGMT_OP_MESH_SEND request with a truncated advertising payload and an inconsistent adv_data_len field.
4. Send the malformed request to the kernel Bluetooth management interface.
5. Trigger asynchronous mesh send processing of the queued malformed command.
6. Cause an out-of-bounds access in kernel Bluetooth code, potentially crashing or destabilizing the system.

How to detect it

There are no reliable public exploitation indicators or known threat-actor campaigns associated with this issue from the provided data. To determine whether exploitation may already have occurred, review kernel logs, system journals, crash dumps, and uptime/reboot telemetry for unexplained crashes or oops events involving the Linux Bluetooth management or mesh send code path. Useful sources include journald, syslog, kern.log, dmesg snapshots, kdump/vmcore records, endpoint telemetry, audit logs for unusual local processes interacting with Bluetooth sockets, and EDR records showing unexpected tools opening AF_BLUETOOTH or HCI management interfaces. Investigate crashes that occur shortly after local processes interact with Bluetooth management, especially on systems where Bluetooth mesh functionality is not normally used. Because the most likely impact is denial of service, evidence may be limited to kernel crash artifacts rather than persistent files, registry changes, or network indicators.

What your security team should do

• Prioritize patching affected Linux endpoints and embedded/edge devices where Bluetooth is enabled and system availability is important.
• Apply vendor kernel updates that include the Bluetooth MGMT mesh send payload length validation fix; reboot systems as required so the fixed kernel is actually running.
• Disable Bluetooth on servers, appliances, and workloads that do not require it.
• Restrict local capabilities and container privileges that could allow access to Bluetooth management interfaces, especially CAP_NET_ADMIN-like access.
• Add monitoring for unexplained kernel oops, panic, reboot, or Bluetooth subsystem faults on systems with Bluetooth enabled.
• Treat exploitation risk as local and currently low-likelihood, but include the fix in normal kernel maintenance because the impact can be a full system denial of service.
• For fleets with embedded or downstream Linux dependencies, confirm vendor firmware or kernel backports include the fix rather than relying only on upstream kernel version numbers.