CVE-2026-53252 is a newly published Linux kernel Bluetooth vulnerability, disclosed through NVD on June 25, 2026, that fixes a memory leak in the
The headline is deceptively narrow: Bluetooth, HCI UART, SRCU, percpu memory, error path. That sounds like the sort of kernel plumbing only driver maintainers and syzkaller dashboards could love. But the important part is not Bluetooth audio or pairing pop-ups; it is resource ownership inside the Linux kernel’s device lifecycle.
The flaw occurs when Bluetooth device initialization fails early, before
That shortcut skips
This is why the CVE is more interesting than its likely severity. It shows how a one-line-looking cleanup imbalance can become a security record once it crosses the boundary from “kernel bug” to “resource exhaustion possibility.” Modern vulnerability catalogs are full of these cases: not cinematic exploit chains, but failure modes that become operationally relevant at scale.
The affected code lives around Linux’s HCI device setup and teardown machinery. HCI, the Host Controller Interface, is the layer that lets the operating system talk to Bluetooth controllers. HCI UART is a transport commonly seen in embedded and board-level designs, where the Bluetooth controller is attached over a serial interface rather than presented as a familiar USB dongle.
The leak is tied to SRCU, or sleepable read-copy update, a synchronization mechanism used in kernel code when readers may need to sleep. SRCU structures require initialization and cleanup. If initialization happens during allocation but cleanup is skipped during release, the kernel does not get all of its memory back.
That is the essence of this CVE. A device allocation path does work early. An early failure prevents registration from completing. A later release path makes a flag-based decision that bypasses the full destructor. The fix restores symmetry: if
There is a temptation to treat fuzz-found leaks as second-class security issues. They often lack the drama of a working exploit, and their initial reproducer may depend on artificial fault injection. But fuzzing has changed kernel security by industrializing the discovery of states that developers rarely hit in ordinary testing. If an object can be partially initialized, referenced, abandoned, and then freed through the wrong path, syzbot will eventually find it.
The fix discussed on the kernel list originally framed the issue as a bypassed destructor. That phrase is the key. Kernel code is full of resource pairs: allocate and free, initialize and destroy, register and unregister, get and put. CVE-2026-53252 is not a failure of cryptography or access control; it is a failure of lifecycle accounting.
Those bugs are rarely flashy, but they are durable. A project can rewrite user interfaces, deprecate command-line tools, or change driver probing behavior, and the underlying rule remains the same: every early exit must clean up everything the function already claimed.
For security teams, that creates an awkward middle ground. The CVE exists. The affected ranges exist. The upstream and stable references exist. But the dashboard-friendly number that usually drives prioritization is missing.
In this case, the technical details point toward a lower-urgency issue than a remotely exploitable memory corruption flaw. The described impact is a memory leak in an early Bluetooth HCI UART failure path. There is no public indication in the provided record of privilege escalation, code execution, information disclosure, or broad remote exploitability.
But “lower urgency” is not the same as “ignore.” Kernel memory leaks can still be relevant in systems where the affected path can be repeatedly triggered, where Bluetooth hardware is unstable, where devices are hot-plugged or reprobed, or where embedded designs use HCI UART transports. Administrators should resist both extremes: do not treat the CVE as a red-alert Bluetooth compromise, and do not dismiss it solely because NVD has not scored it.
That does not mean every distribution exposes the issue in the same way. Enterprise Linux vendors, embedded board vendors, appliance makers, and community distributions routinely backport fixes without moving to the exact upstream version number that appears in a CVE record. A machine that reports an older kernel version may already carry the patch, while a custom kernel built from a nominally newer tree may not.
This is where Linux differs sharply from the mental model many Windows administrators bring from Patch Tuesday. With Windows, the servicing channel and cumulative update history usually answer the first-order question. With Linux, especially outside mainstream distributions, the kernel version string is only the beginning of the inquiry.
The most reliable operational question is not “does my kernel version appear in the CVE text?” It is “does my vendor’s kernel source or advisory include the relevant Bluetooth HCI cleanup fix?” That distinction matters for WSL kernels, containers hosts, security appliances, hypervisors, NAS boxes, IoT gateways, and developer machines running distribution kernels under corporate management.
The risk is not that a Windows 11 laptop suddenly inherits this Linux kernel Bluetooth bug. It does not. The risk is that the Windows administrative perimeter has expanded while patch ownership has become fragmented. A Microsoft-first organization may still depend on Linux kernels in places where nobody thinks to check Bluetooth transport code.
That is especially true for appliances. Security cameras, badge systems, conference-room controllers, gateways, and industrial edge boxes often run Linux kernels with vendor-specific backports. Some of them include Bluetooth controllers for provisioning, telemetry, mobile pairing, or field-service workflows. Many of them are patched slowly.
This CVE is therefore a reminder to inventory by function, not by brand. If a device runs Linux and exposes Bluetooth HCI UART paths, the question belongs in the vendor-management queue even if the device is not “a Linux server” in the traditional sense.
CVE-2026-53252 sits in that ambiguous zone. The public description says early failures in Bluetooth HCI UART configuration leak per-CPU SRCU memory. It does not, by itself, establish an easy attacker path. But in kernel security, availability is not a minor property. A slow leak in kernel memory can degrade a system in ways that are hard to diagnose and difficult to contain without rebooting.
The per-CPU detail also matters. Per-CPU allocations scale with CPU count, so the cost of a leaked structure is not always a single small object. On larger systems, per-CPU memory waste can be more painful than the code size of the bug suggests. On embedded systems, the opposite constraint applies: even small leaks matter when memory headroom is tight.
That is why the right risk posture is conditional. A desktop distribution on a machine with no relevant Bluetooth HCI UART path is unlikely to see meaningful exposure. A test lab repeatedly probing flaky Bluetooth UART hardware, or an embedded product that can be forced through failed controller initialization, deserves closer attention.
The corrected logic removes the special-case danger. Instead of letting
This is not merely prettier code. Security and reliability improve when cleanup paths are centralized. Every extra conditional in a destructor is a chance to skip a resource that was allocated before the condition became false.
Kernel developers have spent years moving toward patterns that make these mistakes harder: managed resource helpers, clearer ownership rules, more aggressive static analysis, and fuzzing that hammers error paths. CVE-2026-53252 shows why those efforts continue. The hardest bugs are often not in what happens when hardware works, but in what happens when it almost works and then fails.
The missing piece is vendor context. A Red Hat, SUSE, Ubuntu, Debian, Fedora, Arch, Android, appliance, or embedded vendor may handle the fix differently. Some will mark a product unaffected because the relevant driver path is disabled or the vulnerable code was not shipped. Others may backport the patch into older kernel lines. Still others may silently absorb it into routine kernel updates.
That reality can be maddening for vulnerability scanners. A scanner that keys off upstream semver ranges may over-report systems that already have a backport. A scanner that waits for NVD enrichment may under-report during the window before scoring and CPE data settle. A scanner that lacks hardware-context awareness may flag Bluetooth code on systems where no usable Bluetooth controller exists.
This is not an argument against scanners. It is an argument against treating scanner output as judgment. For kernel CVEs, the authoritative answer often lives in the distribution changelog, package build metadata, or vendor security notice, not the first public CVE page.
Many laptops use USB-attached Bluetooth controllers. Many servers have no Bluetooth hardware enabled at all. Many cloud instances expose no Bluetooth subsystem to guests. In those environments, this CVE is more likely to be a compliance item than an urgent operational threat.
The more interesting cases are embedded systems and boards where Bluetooth controllers sit behind UART links. These are common in development boards, IoT products, appliances, and custom hardware designs. If initialization can be forced to fail repeatedly, the leak becomes more than a theoretical tidiness issue.
There is also a diagnostic angle. If a system has unexplained kernel memory growth associated with repeated Bluetooth device probe failures, this fix belongs on the shortlist. The symptom will not look like an ordinary process leak in Task Manager or
There is little evidence here for emergency mitigations across typical enterprise fleets. Disabling Bluetooth may be reasonable on servers and appliances where it is not needed, but that is already a common hardening step. Blacklisting modules or altering kernel configuration solely for this CVE will often create more operational risk than it removes.
For Windows administrators responsible for mixed estates, the better move is inventory. Identify Linux systems with Bluetooth hardware or embedded HCI UART usage. Ask vendors whether their kernels include the fix. Make sure vulnerability tools do not leave the issue permanently in limbo because NVD scoring was unavailable when the record first appeared.
This is the boring discipline of security operations, and boring is good. Not every CVE deserves a war room. Some deserve a clean ticket, a vendor check, a scheduled kernel update, and a note explaining why the risk was not escalated.
Attackers like failure paths because developers test them less. Operators hate them because symptoms are intermittent. Maintainers dread them because every fix risks disturbing a delicate lifecycle that has accreted over years.
Linux’s Bluetooth stack is not unique in this respect. Windows drivers, firmware update agents, storage filters, VPN clients, EDR components, and hypervisor integrations all have the same problem. The cleanup path is where engineering intent meets the messy world of partial success.
That makes this CVE a useful teaching case beyond Linux. If a subsystem allocates resources early, registers them later, and uses flags to decide how much cleanup is necessary, the project has created a state machine. The state machine may be implicit, but the bugs will be real.
hci_alloc_dev() error path when early Bluetooth HCI UART setup fails before device registration completes. It is not the kind of bug that should send administrators sprinting toward emergency change windows. It is, however, exactly the kind of kernel flaw that quietly explains why vulnerability management has become harder than simply sorting by CVSS score. The practical lesson is that small lifecycle bugs in shared subsystems still matter, especially when Linux sits underneath appliances, developer workstations, WSL-adjacent tooling, embedded gateways, and the infrastructure Windows shops increasingly depend on.
A Small Bluetooth Leak Lands in a Very Large Kernel
The headline is deceptively narrow: Bluetooth, HCI UART, SRCU, percpu memory, error path. That sounds like the sort of kernel plumbing only driver maintainers and syzkaller dashboards could love. But the important part is not Bluetooth audio or pairing pop-ups; it is resource ownership inside the Linux kernel’s device lifecycle.The flaw occurs when Bluetooth device initialization fails early, before
hci_register_dev() finishes. Under that condition, the HCI_UNREGISTER flag is never set. Later, when the object’s reference count drops to zero, bt_host_release() takes the unregistered-device path and directly frees the HCI device structure with kfree(hdev).That shortcut skips
hci_release_dev(), the destructor path that should unwind resources initialized earlier by hci_alloc_dev(). The missed cleanup is the SRCU structure, which consumes per-CPU memory. One failed initialization is not a catastrophe; repeated failed initializations can become a slow leak in kernel memory that the ordinary process-level tooling administrators reach for may not explain cleanly.This is why the CVE is more interesting than its likely severity. It shows how a one-line-looking cleanup imbalance can become a security record once it crosses the boundary from “kernel bug” to “resource exhaustion possibility.” Modern vulnerability catalogs are full of these cases: not cinematic exploit chains, but failure modes that become operationally relevant at scale.
The Bug Is in the Cleanup, Not the Radio
Bluetooth vulnerabilities tend to make people think about proximity attacks, malicious devices, and the old anxiety that wireless stacks are sprawling attack surfaces bolted onto machines that never asked for them. CVE-2026-53252 is not best understood that way. The issue described in the record is a memory leak in an error path, not a Bluetooth protocol authentication bypass or a remote code execution bug.The affected code lives around Linux’s HCI device setup and teardown machinery. HCI, the Host Controller Interface, is the layer that lets the operating system talk to Bluetooth controllers. HCI UART is a transport commonly seen in embedded and board-level designs, where the Bluetooth controller is attached over a serial interface rather than presented as a familiar USB dongle.
The leak is tied to SRCU, or sleepable read-copy update, a synchronization mechanism used in kernel code when readers may need to sleep. SRCU structures require initialization and cleanup. If initialization happens during allocation but cleanup is skipped during release, the kernel does not get all of its memory back.
That is the essence of this CVE. A device allocation path does work early. An early failure prevents registration from completing. A later release path makes a flag-based decision that bypasses the full destructor. The fix restores symmetry: if
hci_alloc_dev() initializes the resource, the release path must clean it up even for devices that never became fully registered.Syzbot Again Finds the Boring Bug That Matters
The public patch discussion indicates the issue was caught by syzbot, Google’s automated kernel fuzzing system that has spent years turning obscure kernel edge cases into reproducible reports. That matters because this is precisely the category of bug humans are bad at finding by inspection. The normal path looks fine, the unregistration path looks fine, and the failure path only becomes obvious when a fuzzer forces initialization to fail at just the wrong point.There is a temptation to treat fuzz-found leaks as second-class security issues. They often lack the drama of a working exploit, and their initial reproducer may depend on artificial fault injection. But fuzzing has changed kernel security by industrializing the discovery of states that developers rarely hit in ordinary testing. If an object can be partially initialized, referenced, abandoned, and then freed through the wrong path, syzbot will eventually find it.
The fix discussed on the kernel list originally framed the issue as a bypassed destructor. That phrase is the key. Kernel code is full of resource pairs: allocate and free, initialize and destroy, register and unregister, get and put. CVE-2026-53252 is not a failure of cryptography or access control; it is a failure of lifecycle accounting.
Those bugs are rarely flashy, but they are durable. A project can rewrite user interfaces, deprecate command-line tools, or change driver probing behavior, and the underlying rule remains the same: every early exit must clean up everything the function already claimed.
The CVSS Blank Space Is Part of the Story
As of publication, NVD has received the CVE record but has not provided CVSS 4.0, CVSS 3.x, or CVSS 2.0 scores. That absence is not unusual in the current vulnerability ecosystem, but it changes how defenders should read the entry. A blank severity field does not mean “safe,” and it does not mean “critical.” It means the public scoring layer has not yet done the interpretation work that many tools still treat as authoritative.For security teams, that creates an awkward middle ground. The CVE exists. The affected ranges exist. The upstream and stable references exist. But the dashboard-friendly number that usually drives prioritization is missing.
In this case, the technical details point toward a lower-urgency issue than a remotely exploitable memory corruption flaw. The described impact is a memory leak in an early Bluetooth HCI UART failure path. There is no public indication in the provided record of privilege escalation, code execution, information disclosure, or broad remote exploitability.
But “lower urgency” is not the same as “ignore.” Kernel memory leaks can still be relevant in systems where the affected path can be repeatedly triggered, where Bluetooth hardware is unstable, where devices are hot-plugged or reprobed, or where embedded designs use HCI UART transports. Administrators should resist both extremes: do not treat the CVE as a red-alert Bluetooth compromise, and do not dismiss it solely because NVD has not scored it.
Version Ranges Make This a Packaging Problem
The affected-version data is unusually concrete, and that is where Linux vulnerability handling often becomes tedious for Windows-centric IT teams. The record identifies affected stable series and corresponding fixed versions, including 5.15.209 before 5.15.210, 6.1.167 before 6.1.176, 6.6.97 before 6.6.143, 6.12.36 before 6.12.94, 5.10.259 before 5.11, and 6.15.5 before 6.16. It also lists later unaffected points such as 7.0.13 for the 7.0 series and 7.1 as the original commit for the fix.That does not mean every distribution exposes the issue in the same way. Enterprise Linux vendors, embedded board vendors, appliance makers, and community distributions routinely backport fixes without moving to the exact upstream version number that appears in a CVE record. A machine that reports an older kernel version may already carry the patch, while a custom kernel built from a nominally newer tree may not.
This is where Linux differs sharply from the mental model many Windows administrators bring from Patch Tuesday. With Windows, the servicing channel and cumulative update history usually answer the first-order question. With Linux, especially outside mainstream distributions, the kernel version string is only the beginning of the inquiry.
The most reliable operational question is not “does my kernel version appear in the CVE text?” It is “does my vendor’s kernel source or advisory include the relevant Bluetooth HCI cleanup fix?” That distinction matters for WSL kernels, containers hosts, security appliances, hypervisors, NAS boxes, IoT gateways, and developer machines running distribution kernels under corporate management.
Windows Shops Still Own Linux Risk
WindowsForum readers may reasonably ask why a Linux Bluetooth CVE deserves attention here. The answer is that Windows environments no longer stop at Windows endpoints. Most enterprise Windows estates now include Linux in the form of cloud images, Kubernetes nodes, network appliances, CI runners, WSL developer environments, security sensors, and embedded management hardware.The risk is not that a Windows 11 laptop suddenly inherits this Linux kernel Bluetooth bug. It does not. The risk is that the Windows administrative perimeter has expanded while patch ownership has become fragmented. A Microsoft-first organization may still depend on Linux kernels in places where nobody thinks to check Bluetooth transport code.
That is especially true for appliances. Security cameras, badge systems, conference-room controllers, gateways, and industrial edge boxes often run Linux kernels with vendor-specific backports. Some of them include Bluetooth controllers for provisioning, telemetry, mobile pairing, or field-service workflows. Many of them are patched slowly.
This CVE is therefore a reminder to inventory by function, not by brand. If a device runs Linux and exposes Bluetooth HCI UART paths, the question belongs in the vendor-management queue even if the device is not “a Linux server” in the traditional sense.
Memory Leaks Are Availability Bugs Wearing Security Badges
The security industry often struggles to classify memory leaks. They are not always vulnerabilities in the intuitive sense. Many are reliability bugs. Some are only observable under failure injection. Others become denial-of-service vulnerabilities when an attacker can trigger the leaking path repeatedly.CVE-2026-53252 sits in that ambiguous zone. The public description says early failures in Bluetooth HCI UART configuration leak per-CPU SRCU memory. It does not, by itself, establish an easy attacker path. But in kernel security, availability is not a minor property. A slow leak in kernel memory can degrade a system in ways that are hard to diagnose and difficult to contain without rebooting.
The per-CPU detail also matters. Per-CPU allocations scale with CPU count, so the cost of a leaked structure is not always a single small object. On larger systems, per-CPU memory waste can be more painful than the code size of the bug suggests. On embedded systems, the opposite constraint applies: even small leaks matter when memory headroom is tight.
That is why the right risk posture is conditional. A desktop distribution on a machine with no relevant Bluetooth HCI UART path is unlikely to see meaningful exposure. A test lab repeatedly probing flaky Bluetooth UART hardware, or an embedded product that can be forced through failed controller initialization, deserves closer attention.
The Fix Is Elegant Because the Original Assumption Was Brittle
The patch logic is a small morality play about kernel destructors. The original flow assumed that theHCI_UNREGISTER flag could decide whether the device should go through hci_release_dev() or be directly freed. That assumption was brittle because unregistered did not mean uninitialized. A device can fail before registration and still have resources that need structured cleanup.The corrected logic removes the special-case danger. Instead of letting
bt_host_release() bypass the release function for unregistered devices, the cleanup path is made responsible for resources initialized early in allocation. That is how object lifetime code should behave: callers should not need to remember a maze of partially initialized states if the destructor can safely handle them.This is not merely prettier code. Security and reliability improve when cleanup paths are centralized. Every extra conditional in a destructor is a chance to skip a resource that was allocated before the condition became false.
Kernel developers have spent years moving toward patterns that make these mistakes harder: managed resource helpers, clearer ownership rules, more aggressive static analysis, and fuzzing that hammers error paths. CVE-2026-53252 shows why those efforts continue. The hardest bugs are often not in what happens when hardware works, but in what happens when it almost works and then fails.
The NVD Record Is Useful, But It Is Not the Whole Advisory
NVD’s change record provides the basic facts: the CVE identifier, the kernel.org source, the description, the affected file, and stable commit references. It also shows the absence of NVD scoring at the time of publication. That is enough to begin triage, but not enough to finish it.The missing piece is vendor context. A Red Hat, SUSE, Ubuntu, Debian, Fedora, Arch, Android, appliance, or embedded vendor may handle the fix differently. Some will mark a product unaffected because the relevant driver path is disabled or the vulnerable code was not shipped. Others may backport the patch into older kernel lines. Still others may silently absorb it into routine kernel updates.
That reality can be maddening for vulnerability scanners. A scanner that keys off upstream semver ranges may over-report systems that already have a backport. A scanner that waits for NVD enrichment may under-report during the window before scoring and CPE data settle. A scanner that lacks hardware-context awareness may flag Bluetooth code on systems where no usable Bluetooth controller exists.
This is not an argument against scanners. It is an argument against treating scanner output as judgment. For kernel CVEs, the authoritative answer often lives in the distribution changelog, package build metadata, or vendor security notice, not the first public CVE page.
The Practical Exposure Is Narrower Than the Headline
For most readers, the word “Bluetooth” will do too much work. Bluetooth is a common subsystem, but the described failing path is specific: HCI UART configuration fails early, and the HCI device is released without the SRCU cleanup. That narrows the likely exposure compared with a bug in general Bluetooth packet parsing.Many laptops use USB-attached Bluetooth controllers. Many servers have no Bluetooth hardware enabled at all. Many cloud instances expose no Bluetooth subsystem to guests. In those environments, this CVE is more likely to be a compliance item than an urgent operational threat.
The more interesting cases are embedded systems and boards where Bluetooth controllers sit behind UART links. These are common in development boards, IoT products, appliances, and custom hardware designs. If initialization can be forced to fail repeatedly, the leak becomes more than a theoretical tidiness issue.
There is also a diagnostic angle. If a system has unexplained kernel memory growth associated with repeated Bluetooth device probe failures, this fix belongs on the shortlist. The symptom will not look like an ordinary process leak in Task Manager or
top. It will look like the kernel losing memory it should have reclaimed.Administrators Should Patch Normally, Not Theatrically
The right response is straightforward: take the fixed kernel through normal update channels. For mainstream Linux distributions, that means applying vendor kernel updates once they include the relevant stable fix. For custom kernels, it means checking whether the Bluetooth HCI cleanup patch is present in the maintained branch.There is little evidence here for emergency mitigations across typical enterprise fleets. Disabling Bluetooth may be reasonable on servers and appliances where it is not needed, but that is already a common hardening step. Blacklisting modules or altering kernel configuration solely for this CVE will often create more operational risk than it removes.
For Windows administrators responsible for mixed estates, the better move is inventory. Identify Linux systems with Bluetooth hardware or embedded HCI UART usage. Ask vendors whether their kernels include the fix. Make sure vulnerability tools do not leave the issue permanently in limbo because NVD scoring was unavailable when the record first appeared.
This is the boring discipline of security operations, and boring is good. Not every CVE deserves a war room. Some deserve a clean ticket, a vendor check, a scheduled kernel update, and a note explaining why the risk was not escalated.
The Real Signal Is in the Failure Path
The most revealing aspect of CVE-2026-53252 is that the normal path was not the problem. The bug appears when setup fails before registration completes. That is where software quality often decays: in the code that runs only when hardware misbehaves, memory allocation fails, probing aborts, or initialization gets halfway done.Attackers like failure paths because developers test them less. Operators hate them because symptoms are intermittent. Maintainers dread them because every fix risks disturbing a delicate lifecycle that has accreted over years.
Linux’s Bluetooth stack is not unique in this respect. Windows drivers, firmware update agents, storage filters, VPN clients, EDR components, and hypervisor integrations all have the same problem. The cleanup path is where engineering intent meets the messy world of partial success.
That makes this CVE a useful teaching case beyond Linux. If a subsystem allocates resources early, registers them later, and uses flags to decide how much cleanup is necessary, the project has created a state machine. The state machine may be implicit, but the bugs will be real.
What This Bluetooth CVE Should Put on the Patch Board
CVE-2026-53252 should not be inflated into a Bluetooth panic, but it should not disappear into the swamp of unscored kernel CVEs either. Its value is as a precise reminder that vulnerability management must combine upstream facts, vendor packaging, hardware exposure, and operational likelihood.- The vulnerability affects Linux kernel Bluetooth HCI cleanup logic, not Windows Bluetooth components.
- The described impact is a kernel memory leak caused by skipped SRCU cleanup after early HCI UART initialization failure.
- The NVD record was published on June 25, 2026, but NVD had not yet assigned CVSS scores at the time reflected in the record.
- Systems using vendor kernels may already have a backported fix even if their displayed kernel version appears older than an upstream fixed version.
- The highest-priority checks belong on embedded Linux devices, appliances, development boards, and systems that actually use Bluetooth HCI UART paths.
- Most general-purpose Linux fleets can handle the fix through normal kernel update processes unless local evidence shows repeated Bluetooth initialization failures or memory pressure.
References
- Primary source: NVD / Linux Kernel
Published: 2026-06-28T01:53:30-07:00
NVD - CVE-2026-53252
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-06-28T01:53:30-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Official source: nist.gov
National Vulnerability Database
NIST maintains the National Vulnerability Database (NVD), a repository of information on software and hardware flaws that can compromise computer security. This is a key piece of the nation’s cybersecurity infrastructure.www.nist.gov - Related coverage: spinics.net
[PATCH] Bluetooth: fix memory leaks in error path of hci_alloc_dev() — Linux Kernel
Linux Kernel: [PATCH] Bluetooth: fix memory leaks in error path of hci_alloc_dev()
www.spinics.net
- Related coverage: labs.cloudsecurityalliance.org
CSA research note ai vuln discovery velocity disclosure crisis 20260524 csa styled
PDF documentlabs.cloudsecurityalliance.org
