CVE-2026-46138 is a Linux kernel Bluetooth vulnerability published by NVD on May 28, 2026, after kernel.org assigned a CVE to an out-of-bounds read and potential infinite loop in the
The vulnerable code sits in the Linux Bluetooth stack, specifically in the Host Controller Interface event path. HCI is the layer where the operating system talks to the Bluetooth controller, and
The flaw is almost painfully simple. The handler walks through connections in a
That turns malformed or inconsistent controller input into an out-of-bounds read. If the controller reports fewer BIS handles than the kernel expects for the bound connections, or reports
According to the kernel CVE description, the values read beyond the array often exceed
That last detail is the sting. A bad event does not merely produce a one-off parse error; it can trap the Bluetooth event path inside a lock-protected loop. In kernel code, a lock held during an infinite loop is not just a local bug. It can starve related work, wedge subsystem progress, and turn a malformed event into a system stability problem.
That blank space should not be mistaken for insignificance. Kernel Bluetooth vulnerabilities often sit in an awkward scoring zone because exploitability depends on hardware state, Bluetooth enablement, controller behavior, proximity, or local privilege boundaries. The difference between “interesting bug” and “fleet incident” is often operational context rather than the CVE label itself.
Here, the fix strategy is telling. The resolution is not to soldier on after a partial BIG creation event and hope the remaining connections resolve later. The kernel fix terminates the BIG if not all BIS could be set up properly. In other words, the kernel now treats the inconsistent event as a failure of the whole operation rather than trying to continue with mismatched state.
That is the right instinct for kernel protocol code. Once the reported number of elements and the expected connection state diverge, trying to recover inside the same optimistic loop is where memory bugs and state bugs breed. Terminating the operation is blunt, but blunt is often what secure kernel code needs.
The stable kernel references attached to the CVE show that the patch has been routed into multiple stable branches. That matters because Bluetooth bugs do not live only on bleeding-edge desktops. They land in distribution kernels, vendor kernels, embedded systems, and long-lived appliances that may be updated according to very different calendars.
The Linux host receives HCI events from the Bluetooth controller. Depending on the machine, that controller may be integrated over USB, PCIe, UART, or another bus. A malformed HCI event could come from buggy firmware, a compromised controller, emulation, a malicious peripheral path that can influence controller behavior, or a test harness with HCI injection capability. But the CVE text alone does not establish that an arbitrary nearby attacker can reliably trigger the condition from across the room.
This is where good security reporting has to resist melodrama. Bluetooth is a radio protocol, and radio-adjacent bugs invite scary headlines. But the actual trust boundary in this case is between host kernel code and the controller event stream. The controller is a semi-trusted device, not pure software inside the kernel.
That semi-trusted status is precisely why the bug is still important. Operating systems have spent years learning that firmware and devices cannot be treated as perfectly well-behaved. USB devices lie. Wi-Fi firmware crashes. Storage devices return impossible states. Bluetooth controllers are no different. The kernel must validate the length and internal consistency of events even when those events arrive from hardware that the platform nominally trusts.
The old code assumed that the number of BIS handles available in the event would be sufficient for the connections it was about to process. The patch turns that implicit trust into an explicit boundary check. That is not glamorous, but it is the difference between robust device handling and a subsystem that can be wedged by malformed state.
BIGs and BISes are part of that machinery. A Broadcast Isochronous Group contains one or more Broadcast Isochronous Streams. The host stack has to create, track, bind, complete, and tear down these relationships while coordinating with a controller that may be running its own firmware and timing-sensitive state machine.
That complexity is not a Linux-only problem. Windows, macOS, Android, embedded RTOSes, and Linux all have to deal with the same broad trend: peripherals are getting smarter, protocols are getting more layered, and host kernels are expected to keep up without trusting too much. The more state a protocol carries, the more opportunities there are for counters, arrays, handles, and lookup tables to drift out of alignment.
CVE-2026-46138 is a classic example of that drift. The event says one thing about how many BIS handles exist. The host-side connection table says there are bound connections waiting to be assigned handles. The handler walks the host-side state while indexing into the event-side array. Without a guard binding those two sources of truth together, the loop crosses the memory boundary.
For WindowsForum readers, the lesson is not that Bluetooth LE Audio is unsafe or that Linux Bluetooth is uniquely broken. The lesson is that kernel subsystems built around rich device protocols need defensive parsing everywhere. Every count field is a contract. Every flexible array needs a limit check. Every loop over kernel state that consumes device-provided entries must prove it can stop.
An out-of-bounds read in the kernel is never merely a bad pointer arithmetic story. Even if the read does not directly leak secrets to user space, it means kernel control flow is being influenced by memory outside the intended structure. In this case, the more immediate consequence is that invalid handle values are rejected, leaving the same connection state intact and allowing the loop to repeat.
The infinite loop is the operationally visible part. If a Bluetooth event handler spins while holding
On a developer laptop, that may be annoying. On a kiosk, a point-of-sale device, a conference-room system, a medical cart, or an industrial tablet using Linux under the hood, a reliable subsystem hang can become a real availability issue. Security is not only confidentiality and privilege escalation; it is also whether the endpoint keeps functioning when exposed to malformed inputs.
This is why the CVSS score, once assigned, should not be read in isolation. A medium-severity kernel denial-of-service issue on a single-user desktop might be a patch-when-convenient item. The same class of bug on a fleet of unattended Linux devices with Bluetooth enabled by default might deserve a faster maintenance window.
The old patch-management model relied heavily on enriched CVE records: wait for a score, read the affected versions, map the advisory to packages, and prioritize. With fast-moving kernel CVEs, the authoritative early signal is often the upstream commit and the distribution’s kernel update, not the finished NVD page.
That does not mean every fresh kernel CVE is urgent. It means the first triage question should be practical: does this subsystem exist on my systems, is the feature enabled, and has my vendor shipped a fixed kernel? For CVE-2026-46138, the relevant conditions include Linux kernel exposure, Bluetooth support, and code paths related to LE BIG creation. Many servers will have Bluetooth absent or disabled. Many laptops and workstations will not.
For enterprises, the best answer is boring and repeatable. Inventory Bluetooth-capable Linux endpoints. Know which kernel streams they run. Track vendor kernel advisories rather than upstream commits alone. Disable Bluetooth where it has no business need. And for devices that do use Bluetooth, treat kernel updates as part of the endpoint security program rather than as a discretionary desktop polish item.
The uncomfortable truth is that kernel CVE volume has outgrown purely manual triage. A single Linux fleet can receive dozens of CVEs whose practical risk ranges from “irrelevant to this hardware” to “patch before the weekend.” The organizations that cope best are those with asset context, not those with the longest spreadsheet of CVSS numbers.
Linux appears in Hyper-V guests, WSL-backed workflows, developer laptops, CI runners, container hosts, network appliances, security tools, NAS boxes, Kubernetes nodes, and edge devices. Some of those systems have Bluetooth disabled or physically absent. Others are laptops and small-form-factor devices where Bluetooth is very much alive.
The more interesting parallel is architectural. Windows has its own history of device-stack vulnerabilities, malformed driver inputs, and trust-boundary failures between hardware, firmware, and the OS. The Linux bug is a reminder that the modern endpoint attack surface is not just browsers and Office documents. It is also the quiet set of protocol parsers listening to devices and radios.
For Windows administrators responsible for mixed fleets, this is where policy matters more than panic. If Bluetooth is not needed on Linux servers, disable it at the service, kernel module, BIOS, or device policy level where appropriate. If Bluetooth is needed on workstations, ensure those systems receive vendor kernel updates promptly. If a Linux device is managed by an appliance vendor, ask when the patched kernel lands rather than assuming upstream stable commits magically protect the box.
The same logic applies to Windows: reduce unused radios, keep driver and firmware channels patched, and avoid treating device security as separate from OS security. The boundary between operating system and peripheral is now one of the most interesting places for bugs to hide.
There is always temptation in systems code to be permissive. Maybe a partial event can be salvaged. Maybe the controller will send another event. Maybe the remaining connection can be found in the next iteration. This is how code accumulates exception paths that are never as well tested as the successful path.
Failing closed is not always user-friendly. A headset or broadcast audio session may fail to initialize. A log may fill with errors. A vendor firmware bug may become visible to users who previously saw only silent recovery. But in kernel space, visible failure is usually preferable to silent memory access outside a declared array.
The revised behavior also creates cleaner diagnostics. If a controller sends an inconsistent completion event, the host tears down the attempted BIG rather than leaving connections in a state that causes the same lookup to repeat. That gives developers and vendors a clearer fault boundary: the operation failed because the event did not contain enough valid handles.
This is how mature kernel hardening often looks. It is not always a new mitigation with a brand name. Sometimes it is one more index check, one more bounds-aware loop, and one fewer assumption that a device-provided count will line up with host-side state.
Distribution maintainers will decide exactly how the upstream stable fixes map to their supported kernels. That is what administrators should watch. A commit in an upstream stable tree is important evidence, but the actionable event for most organizations is a vendor package update for Ubuntu, Debian, Fedora, Red Hat family distributions, SUSE, Arch, or the appliance vendor’s own kernel channel.
Home users on rolling distributions should receive the fix through normal kernel updates once packaged. Users on long-term support distributions should look for security kernel updates or point releases. Embedded and appliance users have the harder task, because Bluetooth stacks may be baked into vendor images that update slowly.
The best near-term mitigation, where patching is delayed, is exposure reduction. If Bluetooth is not required, turn it off. If the kernel module is not needed, prevent it from loading. If the hardware can be disabled in firmware settings on fixed-purpose systems, that may be cleaner than relying on user-space service state alone.
hci_le_create_big_complete_evt() event handler. The bug is not a Windows vulnerability, but it matters to WindowsForum readers because many of us run Linux somewhere: on dual-boot laptops, developer workstations, WSL-adjacent lab boxes, hypervisors, appliances, and small servers. Its practical lesson is larger than Bluetooth. Modern kernel security is increasingly about obscure state machines failing safely when hardware, firmware, or hostile inputs violate assumptions.
A Bluetooth Corner Case Becomes a Kernel Availability Problem
The vulnerable code sits in the Linux Bluetooth stack, specifically in the Host Controller Interface event path. HCI is the layer where the operating system talks to the Bluetooth controller, and hci_le_create_big_complete_evt() handles completion of a Bluetooth LE operation involving a Broadcast Isochronous Group, or BIG. That terminology sounds niche because it is: this is part of the Bluetooth LE Audio-era machinery for broadcast audio streams and related isochronous transport.The flaw is almost painfully simple. The handler walks through connections in a
BT_BOUND state for a given BIG handle and reads entries from a flexible bis_handle[] array supplied in the event. The event also contains num_bis, the number of valid BIS handles present. The old logic failed to check that the loop index stayed below num_bis before reading the next array element.That turns malformed or inconsistent controller input into an out-of-bounds read. If the controller reports fewer BIS handles than the kernel expects for the bound connections, or reports
num_bis=0 while such connections exist, the kernel can read past the valid event payload into adjacent heap memory. The usual security shorthand here is OOB read, but the denial-of-service angle is the more interesting part.According to the kernel CVE description, the values read beyond the array often exceed
HCI_CONN_HANDLE_MAX, which causes hci_conn_set_handle() to reject them. Because the connection remains in BT_BOUND, the next lookup finds the same connection again. The loop does not make forward progress, and it does so while holding hci_dev_lock.That last detail is the sting. A bad event does not merely produce a one-off parse error; it can trap the Bluetooth event path inside a lock-protected loop. In kernel code, a lock held during an infinite loop is not just a local bug. It can starve related work, wedge subsystem progress, and turn a malformed event into a system stability problem.
The Fix Says More Than the CVE Score Will
As of the initial NVD record, CVE-2026-46138 was still awaiting enrichment. NVD had not assigned CVSS 4.0, 3.x, or 2.0 scores in the record supplied with the disclosure. That means administrators looking for a neat “high,” “medium,” or “low” verdict may initially find a blank space where the risk number normally sits.That blank space should not be mistaken for insignificance. Kernel Bluetooth vulnerabilities often sit in an awkward scoring zone because exploitability depends on hardware state, Bluetooth enablement, controller behavior, proximity, or local privilege boundaries. The difference between “interesting bug” and “fleet incident” is often operational context rather than the CVE label itself.
Here, the fix strategy is telling. The resolution is not to soldier on after a partial BIG creation event and hope the remaining connections resolve later. The kernel fix terminates the BIG if not all BIS could be set up properly. In other words, the kernel now treats the inconsistent event as a failure of the whole operation rather than trying to continue with mismatched state.
That is the right instinct for kernel protocol code. Once the reported number of elements and the expected connection state diverge, trying to recover inside the same optimistic loop is where memory bugs and state bugs breed. Terminating the operation is blunt, but blunt is often what secure kernel code needs.
The stable kernel references attached to the CVE show that the patch has been routed into multiple stable branches. That matters because Bluetooth bugs do not live only on bleeding-edge desktops. They land in distribution kernels, vendor kernels, embedded systems, and long-lived appliances that may be updated according to very different calendars.
The Real Attack Surface Is the Controller Boundary
The natural first question is whether this is remotely exploitable over Bluetooth. The responsible answer is more cautious than exciting: the public CVE language describes a controller sending a malformed LE Create BIG Complete event, not a fully documented over-the-air attack chain. That distinction matters.The Linux host receives HCI events from the Bluetooth controller. Depending on the machine, that controller may be integrated over USB, PCIe, UART, or another bus. A malformed HCI event could come from buggy firmware, a compromised controller, emulation, a malicious peripheral path that can influence controller behavior, or a test harness with HCI injection capability. But the CVE text alone does not establish that an arbitrary nearby attacker can reliably trigger the condition from across the room.
This is where good security reporting has to resist melodrama. Bluetooth is a radio protocol, and radio-adjacent bugs invite scary headlines. But the actual trust boundary in this case is between host kernel code and the controller event stream. The controller is a semi-trusted device, not pure software inside the kernel.
That semi-trusted status is precisely why the bug is still important. Operating systems have spent years learning that firmware and devices cannot be treated as perfectly well-behaved. USB devices lie. Wi-Fi firmware crashes. Storage devices return impossible states. Bluetooth controllers are no different. The kernel must validate the length and internal consistency of events even when those events arrive from hardware that the platform nominally trusts.
The old code assumed that the number of BIS handles available in the event would be sufficient for the connections it was about to process. The patch turns that implicit trust into an explicit boundary check. That is not glamorous, but it is the difference between robust device handling and a subsystem that can be wedged by malformed state.
Bluetooth LE Audio Expands the Weird Parts of the Kernel
Bluetooth LE Audio has been one of the quieter expansions of consumer and enterprise endpoint complexity. It brings better broadcast audio, lower-power audio transport, and support for newer device classes. It also introduces more protocol machinery for the kernel to parse and reconcile.BIGs and BISes are part of that machinery. A Broadcast Isochronous Group contains one or more Broadcast Isochronous Streams. The host stack has to create, track, bind, complete, and tear down these relationships while coordinating with a controller that may be running its own firmware and timing-sensitive state machine.
That complexity is not a Linux-only problem. Windows, macOS, Android, embedded RTOSes, and Linux all have to deal with the same broad trend: peripherals are getting smarter, protocols are getting more layered, and host kernels are expected to keep up without trusting too much. The more state a protocol carries, the more opportunities there are for counters, arrays, handles, and lookup tables to drift out of alignment.
CVE-2026-46138 is a classic example of that drift. The event says one thing about how many BIS handles exist. The host-side connection table says there are bound connections waiting to be assigned handles. The handler walks the host-side state while indexing into the event-side array. Without a guard binding those two sources of truth together, the loop crosses the memory boundary.
For WindowsForum readers, the lesson is not that Bluetooth LE Audio is unsafe or that Linux Bluetooth is uniquely broken. The lesson is that kernel subsystems built around rich device protocols need defensive parsing everywhere. Every count field is a contract. Every flexible array needs a limit check. Every loop over kernel state that consumes device-provided entries must prove it can stop.
A Denial of Service Can Still Be a Serious Security Bug
Security teams sometimes discount out-of-bounds reads when the public description does not show data exfiltration. They also discount infinite loops when no privilege escalation is obvious. That instinct is understandable, but in kernel space it can be dangerous.An out-of-bounds read in the kernel is never merely a bad pointer arithmetic story. Even if the read does not directly leak secrets to user space, it means kernel control flow is being influenced by memory outside the intended structure. In this case, the more immediate consequence is that invalid handle values are rejected, leaving the same connection state intact and allowing the loop to repeat.
The infinite loop is the operationally visible part. If a Bluetooth event handler spins while holding
hci_dev_lock, the Bluetooth subsystem can become stuck. Depending on the kernel configuration, workload, and where the system is in its power-management or device-management path, that may show up as broken Bluetooth, a hung worker, system sluggishness, or worse.On a developer laptop, that may be annoying. On a kiosk, a point-of-sale device, a conference-room system, a medical cart, or an industrial tablet using Linux under the hood, a reliable subsystem hang can become a real availability issue. Security is not only confidentiality and privilege escalation; it is also whether the endpoint keeps functioning when exposed to malformed inputs.
This is why the CVSS score, once assigned, should not be read in isolation. A medium-severity kernel denial-of-service issue on a single-user desktop might be a patch-when-convenient item. The same class of bug on a fleet of unattended Linux devices with Bluetooth enabled by default might deserve a faster maintenance window.
The NVD Lag Is Now Part of the Patch-Management Story
The CVE record was published with NVD enrichment still pending. That is increasingly common in the Linux kernel CVE era, where identifiers can appear rapidly after fixes are recognized, while downstream scoring and metadata lag behind. For administrators, this changes the workflow.The old patch-management model relied heavily on enriched CVE records: wait for a score, read the affected versions, map the advisory to packages, and prioritize. With fast-moving kernel CVEs, the authoritative early signal is often the upstream commit and the distribution’s kernel update, not the finished NVD page.
That does not mean every fresh kernel CVE is urgent. It means the first triage question should be practical: does this subsystem exist on my systems, is the feature enabled, and has my vendor shipped a fixed kernel? For CVE-2026-46138, the relevant conditions include Linux kernel exposure, Bluetooth support, and code paths related to LE BIG creation. Many servers will have Bluetooth absent or disabled. Many laptops and workstations will not.
For enterprises, the best answer is boring and repeatable. Inventory Bluetooth-capable Linux endpoints. Know which kernel streams they run. Track vendor kernel advisories rather than upstream commits alone. Disable Bluetooth where it has no business need. And for devices that do use Bluetooth, treat kernel updates as part of the endpoint security program rather than as a discretionary desktop polish item.
The uncomfortable truth is that kernel CVE volume has outgrown purely manual triage. A single Linux fleet can receive dozens of CVEs whose practical risk ranges from “irrelevant to this hardware” to “patch before the weekend.” The organizations that cope best are those with asset context, not those with the longest spreadsheet of CVSS numbers.
Windows Shops Should Not Look Away
It would be easy for a Windows-centered audience to file this under “Linux problem” and move on. That would be a mistake, not because CVE-2026-46138 threatens Windows directly, but because almost no Windows environment is Windows-only anymore.Linux appears in Hyper-V guests, WSL-backed workflows, developer laptops, CI runners, container hosts, network appliances, security tools, NAS boxes, Kubernetes nodes, and edge devices. Some of those systems have Bluetooth disabled or physically absent. Others are laptops and small-form-factor devices where Bluetooth is very much alive.
The more interesting parallel is architectural. Windows has its own history of device-stack vulnerabilities, malformed driver inputs, and trust-boundary failures between hardware, firmware, and the OS. The Linux bug is a reminder that the modern endpoint attack surface is not just browsers and Office documents. It is also the quiet set of protocol parsers listening to devices and radios.
For Windows administrators responsible for mixed fleets, this is where policy matters more than panic. If Bluetooth is not needed on Linux servers, disable it at the service, kernel module, BIOS, or device policy level where appropriate. If Bluetooth is needed on workstations, ensure those systems receive vendor kernel updates promptly. If a Linux device is managed by an appliance vendor, ask when the patched kernel lands rather than assuming upstream stable commits magically protect the box.
The same logic applies to Windows: reduce unused radios, keep driver and firmware channels patched, and avoid treating device security as separate from OS security. The boundary between operating system and peripheral is now one of the most interesting places for bugs to hide.
The Kernel Did the Sensible Thing by Failing the Whole Operation
The fix described for CVE-2026-46138 terminates the BIG when not all BIS streams can be set up correctly. That may sound like an implementation detail, but it is the philosophical core of the patch. When protocol state cannot be reconciled, stop the operation.There is always temptation in systems code to be permissive. Maybe a partial event can be salvaged. Maybe the controller will send another event. Maybe the remaining connection can be found in the next iteration. This is how code accumulates exception paths that are never as well tested as the successful path.
Failing closed is not always user-friendly. A headset or broadcast audio session may fail to initialize. A log may fill with errors. A vendor firmware bug may become visible to users who previously saw only silent recovery. But in kernel space, visible failure is usually preferable to silent memory access outside a declared array.
The revised behavior also creates cleaner diagnostics. If a controller sends an inconsistent completion event, the host tears down the attempted BIG rather than leaving connections in a state that causes the same lookup to repeat. That gives developers and vendors a clearer fault boundary: the operation failed because the event did not contain enough valid handles.
This is how mature kernel hardening often looks. It is not always a new mitigation with a brand name. Sometimes it is one more index check, one more bounds-aware loop, and one fewer assumption that a device-provided count will line up with host-side state.
The Practical Reading for Patch Queues
For most users, CVE-2026-46138 is not a reason to rip out Bluetooth adapters or treat every nearby device as hostile. It is a reason to make sure Linux kernels are current, especially on machines where Bluetooth is enabled and actively used. The absence of an initial NVD score should not delay routine patching.Distribution maintainers will decide exactly how the upstream stable fixes map to their supported kernels. That is what administrators should watch. A commit in an upstream stable tree is important evidence, but the actionable event for most organizations is a vendor package update for Ubuntu, Debian, Fedora, Red Hat family distributions, SUSE, Arch, or the appliance vendor’s own kernel channel.
Home users on rolling distributions should receive the fix through normal kernel updates once packaged. Users on long-term support distributions should look for security kernel updates or point releases. Embedded and appliance users have the harder task, because Bluetooth stacks may be baked into vendor images that update slowly.
The best near-term mitigation, where patching is delayed, is exposure reduction. If Bluetooth is not required, turn it off. If the kernel module is not needed, prevent it from loading. If the hardware can be disabled in firmware settings on fixed-purpose systems, that may be cleaner than relying on user-space service state alone.
This Bug Belongs in the “Small Patch, Real Consequences” Folder
CVE-2026-46138 is unlikely to become the celebrity vulnerability of the year. It has no catchy name, no public exploit in the supplied record, and no initial NVD score to drive dashboard drama. But it is exactly the sort of kernel flaw that rewards disciplined maintenance.- The vulnerability affects the Linux kernel Bluetooth HCI event path, not Microsoft Windows itself.
- The bug is an out-of-bounds read caused by failing to check the
bis_handle[]index againstnum_bis. - The most visible failure mode is an infinite loop while
hci_dev_lockis held, which can create a denial-of-service condition in the Bluetooth subsystem. - The public description does not prove a simple over-the-air exploit path, so risk depends heavily on Bluetooth hardware, controller behavior, and system exposure.
- The upstream fix changes the failure mode by terminating the BIG when all BIS handles cannot be set up correctly.
- Administrators should prioritize vendor kernel updates for Bluetooth-capable Linux systems and disable Bluetooth where it is unnecessary.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:07:55-07:00
NVD - CVE-2026-46138
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:07:55-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: app.opencve.io
Linux CVEs and Security Vulnerabilities - OpenCVE
Explore the latest vulnerabilities and security issues of Linux in the CVE database
app.opencve.io
- Related coverage: spinics.net
[PATCH] Bluetooth: hci_event: fix OOB read and infinite loop in hci_le_create_big_complete_evt — Linux Kernel
Linux Kernel: [PATCH] Bluetooth: hci_event: fix OOB read and infinite loop in hci_le_create_big_complete_evt
www.spinics.net
- Related coverage: patchsiren.com
CVE-2026-31771: Linux kernel Bluetooth HCI event handling flaw fixed in 2026
Linux kernel Bluetooth HCI event handling flaw fixed after wake-reason storage was moved behind validation. Affects kernels from 5.10 through 6.19.12 and 7.0 rc
patchsiren.com
