CVE-2026-46186 is a newly published Linux kernel vulnerability, disclosed by kernel.org and listed by NVD on May 28, 2026, in the Bluetooth virtio_bt driver’s receive path, where malformed backend-supplied packets can reach core Bluetooth handling without minimum header-length validation. It is not the kind of bug that should send every desktop user sprinting for the power switch. But it is exactly the kind of small boundary-check failure that matters in virtualized Linux environments, where a “device” may really be a trust boundary wearing a driver costume.
The fix is almost comically modest: after stripping the packet-type byte, verify that the remaining buffer is long enough for the fixed HCI header that the packet type promises. The lesson is larger. Modern kernel security is increasingly about refusing to let paravirtualized hardware, firmware-shaped interfaces, and host-provided backends smuggle ambiguity into code that was written as if the next layer had already done the boring checks.
The vulnerability sits in
In the vulnerable path,
The mistake was not validating that minimum before handing the packet onward. A backend could present a buffer that was technically long enough to contain the packet-type byte but not long enough to contain the header implied by that byte. Once the driver pulled the type byte off the front, the remaining socket buffer could be empty.
That sounds like a trivial malformed input case, and in a well-layered kernel it should be. The problem is that the next layer was willing to inspect fields based on the packet type. In one described path, an ACL packet classification routine can read the ACL handle field when certain Bluetooth ISO-related connection types are active, even though the buffer no longer contains the bytes that make up that header.
That distinction narrows the blast radius, but it does not make the flaw academic. Virtualization has spent years turning what used to be local machine assumptions into distributed trust relationships. A guest kernel may be consuming input from a host process, a device model, a service VM, a testing harness, or an emulated backend written by someone else entirely.
In that architecture, backend-supplied is not a synonym for safe. It is a warning label. The backend might be malicious, compromised, misconfigured, fuzzing-adjacent, or simply buggy in a way that produces impossible packets. The guest kernel still has to defend itself.
That is why the patch is framed as hardening against an untrusted backend. The driver should not assume that because a virtqueue completion exists, the completed buffer is semantically valid. It should not assume that packet classification code downstream will be happy with whatever length remains. And it should not assume that a one-byte receive completion is harmless merely because a previous patch bounded the total receive length.
That is the entire fix in spirit. It is not a cryptographic redesign, not a Bluetooth protocol overhaul, not a new mitigation framework. It is a reminder that input validation is not a ceremony performed once at the outer wall; it is a contract that must be renewed at every semantic transition.
The interesting part is the interaction with an earlier hardening change. The CVE text notes that a preceding patch bounded the backend-supplied
That pattern shows up repeatedly in kernel bugs. One patch makes an input “safe” in a gross memory-allocation sense; the next bug emerges in a semantic sense. The buffer is not too large. It is not negative. It is not outside the allocation. It is merely too short for the meaning the code assigns to it.
But paravirtualization can also lull people into thinking of the backend as part of the same cooperative machine. In a narrow deployment, that may be close to true. In a cloud, lab, sandbox, nested-virtualization stack, or desktop hypervisor with device sharing, it is a more dangerous assumption.
The history of virtualization security is full of bugs at exactly this seam. The guest receives a length, a descriptor, a header, or a completion from a component that is “below” it in the stack. The code treats that value as if it came from a trusted device. The attacker treats it as a programmable input surface.
CVE-2026-46186 is not evidence that VirtIO Bluetooth is uniquely hazardous. It is evidence that every paravirtualized device driver has to be written with the same hostility that kernel developers already apply to network packets and USB descriptors. The attack surface may be narrower, but the privilege boundary is sharper.
That matters for WindowsForum readers who run Linux in virtual machines, operate mixed hypervisor fleets, or maintain CI environments that boot kernels under emulation. The affected code is more relevant to guests configured with VirtIO Bluetooth support than to ordinary Bluetooth usage on bare metal. A Windows 11 laptop dual-booting Linux is not automatically in the same exposure category as a guest consuming a host-provided virtio Bluetooth backend.
Still, specialized does not mean irrelevant. Niche drivers often matter precisely because they sit in high-privilege contexts and receive complex input from unusual places. They may be less exercised by mainstream users, less visible to administrators, and less likely to be part of someone’s mental model when hardening a virtualization environment.
The practical question is therefore not “Do I use Bluetooth?” It is “Can any of my Linux guests load this driver or consume this kind of backend?” For many users, the answer will be no. For virtualization-heavy shops, it is worth checking rather than guessing.
CVSS is useful as a sorting tool, but kernel vulnerabilities often arrive with incomplete scoring context. The score depends on assumptions about attacker position, required privileges, impact, and exploitability. For a VirtIO Bluetooth bug, those assumptions are especially deployment-specific.
A malicious backend in a hostile hosting environment is a different story from a benign local hypervisor on a developer workstation. A guest where the driver is unavailable is different from one where the module can be loaded. A theoretical out-of-bounds read of uninitialized receive-buffer data is different from a demonstrated privilege escalation or denial of service.
That uncertainty should lead to better triage, not complacency. The right operational stance is simple: if your kernels include the affected code and your environments expose the device path, take the stable update. If they do not, document why and move on. The absence of a neat severity badge is not a substitute for exposure analysis.
That rate limiting is not cosmetic. If malformed packets can be generated at will, a naive error path can become a log-flooding problem. A fix that prevents a memory-safety issue should not hand the attacker an easy denial-of-service lever through system logs.
The default path for unknown packet types remains to free the socket buffer. That is also telling. The driver already knew what to do with packet types it did not recognize. The missing part was not the unknown case; it was the known-but-too-short case.
Those are often the most dangerous inputs. Code tends to defend against values outside the enum and forget that valid labels can be attached to invalid bodies. A packet that says “ACL data” but contains no ACL header is more treacherous than a packet that says nothing intelligible at all.
Backporting is where kernel security becomes operationally messy. The same logical fix may appear under different commit IDs in different stable lines. Distribution advisories may use their own package versions. Enterprise kernels may carry the patch without changing the upstream version number in a way that a casual
Administrators should resist the urge to judge exposure only by upstream kernel version. The better test is whether the vendor kernel contains the virtio Bluetooth header-length validation patch. In practice, that means tracking your distribution’s security advisory, checking changelogs, or inspecting the patched source if you maintain custom kernels.
For cloud and virtualization vendors, the question cuts both ways. Guest kernels need the fix to defend themselves against malformed backend input. Host-side or service-side components that provide virtual Bluetooth devices should also be reviewed, because a security boundary that relies on “the guest will parse this sanely” is a poor boundary.
VirtIO itself is common in virtualization ecosystems that Windows administrators encounter indirectly, from KVM-backed infrastructure to virtual appliances shipped by vendors. Even if Hyper-V’s synthetic device model is a different stack, the security lesson transfers cleanly: virtual devices are not trusted just because they are convenient.
The Windows world has its own long history of paravirtualized drivers, guest tools, enhanced session features, clipboard sharing, file sharing, GPU virtualization, and device redirection. Each feature exists to make virtual machines feel less isolated. Each one also creates an input path that crosses a boundary users may not think about.
CVE-2026-46186 is therefore not “a Windows vulnerability,” but it is a Windows admin story. The modern Windows estate is hybrid by default. A vulnerability in a Linux guest driver can affect the reliability and isolation assumptions of the systems that Windows teams build, monitor, and patch.
Out-of-bounds reads in the kernel can have varied consequences. Sometimes they are benign in practice. Sometimes they produce crashes, leaks, or state confusion. Sometimes they become useful only when chained with another primitive. Responsible analysis has to avoid both extremes: this is neither a proven catastrophe nor a harmless typo.
The packet-type coverage broadens the concern. The CVE description says the same hazard exists for every accepted packet type because none of the switch cases checked the payload against the fixed header size before handing it off. The highlighted ACL path is the illustrative one, not the only conceptual flaw.
That is why the fix validates all four accepted types. Security patches that close only the observed crash path often age badly. This one appears to close the class of too-short fixed-header handoffs in the driver, which is the right instinct.
CVE-2026-46186 lives in the gap between those questions. The preceding bounds check made sure the backend did not claim a receive completion larger than the available buffer or smaller than one byte. But one byte is only enough to identify the packet type, not enough to contain the packet.
This is why fuzzers keep finding bugs in mature subsystems. They are very good at generating inputs that satisfy the first validator and violate the second parser’s expectations. Humans tend to think in terms of valid messages and invalid messages. Attackers, fuzzers, and broken devices operate in the gray middle: valid prefix, invalid body.
The most durable kernel hardening happens when developers make each layer locally skeptical. A caller should validate before calling, and a callee should avoid assuming the caller was perfect. That can feel redundant until the day a one-byte packet proves it was not.
VirtIO devices often move structured data with explicit or implicit headers. Drivers may pull a type byte, inspect a length field, cast a buffer to a structure, or pass an
The Linux kernel community has become far better at this kind of hardening, helped by sanitizers, fuzzers, static analysis, and a steady stream of stable backports. But the economics remain brutal. Every driver is a small parser. Every parser is a potential security boundary. Every security boundary is only as strong as its least glamorous length check.
For enterprises, that means the patch management answer is only part of the answer. The strategic move is reducing unnecessary virtual device exposure. If a guest does not need a virtual Bluetooth device, do not provide one. If a lab image loads modules it never uses, trim it. If a VM template enables broad device sharing for convenience, revisit the defaults.
That creates friction for teams whose patch queues are driven by dashboards. A vulnerability with no score may appear less urgent than one with a dramatic red number, even when the unscored issue is directly relevant to a production architecture. Conversely, a high score on an irrelevant component can consume attention because it looks worse in the tool.
The answer is not to abandon scoring. It is to treat scoring as the beginning of triage rather than the end. For this CVE, the decisive questions are architectural: whether Linux guests include
That kind of triage is harder to automate, but it is exactly where experienced administrators earn their keep. A scanner can tell you a package version. It cannot always tell you whether a virtual Bluetooth backend is reachable in your threat model.
The concrete lessons are refreshingly specific:
The fix is almost comically modest: after stripping the packet-type byte, verify that the remaining buffer is long enough for the fixed HCI header that the packet type promises. The lesson is larger. Modern kernel security is increasingly about refusing to let paravirtualized hardware, firmware-shaped interfaces, and host-provided backends smuggle ambiguity into code that was written as if the next layer had already done the boring checks.
A One-Byte Packet Walked Into the Bluetooth Stack
The vulnerability sits in virtio_bt, the Linux driver that lets a guest operating system talk to a Bluetooth controller exposed through the VirtIO framework. VirtIO is the plumbing that makes many virtual devices fast and relatively clean: network cards, block devices, consoles, random-number devices, and, in this case, Bluetooth. The guest sees a device; the hypervisor or backend supplies the behavior.In the vulnerable path,
virtbt_rx_handle() reads a leading packet-type byte from an incoming receive buffer and then passes the rest of the packet into the Bluetooth HCI core. That first byte says whether the frame is an event, ACL data, SCO data, or ISO data packet. Each of those packet classes has a minimum fixed header size.The mistake was not validating that minimum before handing the packet onward. A backend could present a buffer that was technically long enough to contain the packet-type byte but not long enough to contain the header implied by that byte. Once the driver pulled the type byte off the front, the remaining socket buffer could be empty.
That sounds like a trivial malformed input case, and in a well-layered kernel it should be. The problem is that the next layer was willing to inspect fields based on the packet type. In one described path, an ACL packet classification routine can read the ACL handle field when certain Bluetooth ISO-related connection types are active, even though the buffer no longer contains the bytes that make up that header.
The Bug Is Small Because the Trust Boundary Is Not
A natural reaction to this CVE is to ask whether Bluetooth is remotely exploitable here. That is the wrong first question. The issue is not a random Bluetooth radio packet arriving over the air and popping a laptop. The CVE description points at an untrusted backend supplying receive buffers to a VirtIO Bluetooth device.That distinction narrows the blast radius, but it does not make the flaw academic. Virtualization has spent years turning what used to be local machine assumptions into distributed trust relationships. A guest kernel may be consuming input from a host process, a device model, a service VM, a testing harness, or an emulated backend written by someone else entirely.
In that architecture, backend-supplied is not a synonym for safe. It is a warning label. The backend might be malicious, compromised, misconfigured, fuzzing-adjacent, or simply buggy in a way that produces impossible packets. The guest kernel still has to defend itself.
That is why the patch is framed as hardening against an untrusted backend. The driver should not assume that because a virtqueue completion exists, the completed buffer is semantically valid. It should not assume that packet classification code downstream will be happy with whatever length remains. And it should not assume that a one-byte receive completion is harmless merely because a previous patch bounded the total receive length.
Header Lengths Are Boring Until They Become Memory Safety
The technical core of CVE-2026-46186 is a missing set of minimum-length checks. After removing thepkt_type byte, the driver now requires enough data for the relevant HCI header: two bytes for an event header, four for ACL, three for SCO, and four for ISO. If the length is too short, the packet is dropped and the error is rate-limited.That is the entire fix in spirit. It is not a cryptographic redesign, not a Bluetooth protocol overhaul, not a new mitigation framework. It is a reminder that input validation is not a ceremony performed once at the outer wall; it is a contract that must be renewed at every semantic transition.
The interesting part is the interaction with an earlier hardening change. The CVE text notes that a preceding patch bounded the backend-supplied
used.len value to a sane range, from one byte up to the receive buffer size. That closes one class of bad lengths, but it leaves a narrower malformed case: a one-byte completion is valid enough to pass the outer bound check and invalid enough to confuse the packet parser after the type byte is removed.That pattern shows up repeatedly in kernel bugs. One patch makes an input “safe” in a gross memory-allocation sense; the next bug emerges in a semantic sense. The buffer is not too large. It is not negative. It is not outside the allocation. It is merely too short for the meaning the code assigns to it.
VirtIO Makes Devices Faster, Not Magically Trustworthy
VirtIO’s success is built on a simple idea: avoid pretending every virtual machine needs a perfect emulation of old physical hardware. Give the guest a paravirtualized device interface designed for virtualization, and both host and guest can move data with less overhead. That idea has been enormously useful.But paravirtualization can also lull people into thinking of the backend as part of the same cooperative machine. In a narrow deployment, that may be close to true. In a cloud, lab, sandbox, nested-virtualization stack, or desktop hypervisor with device sharing, it is a more dangerous assumption.
The history of virtualization security is full of bugs at exactly this seam. The guest receives a length, a descriptor, a header, or a completion from a component that is “below” it in the stack. The code treats that value as if it came from a trusted device. The attacker treats it as a programmable input surface.
CVE-2026-46186 is not evidence that VirtIO Bluetooth is uniquely hazardous. It is evidence that every paravirtualized device driver has to be written with the same hostility that kernel developers already apply to network packets and USB descriptors. The attack surface may be narrower, but the privilege boundary is sharper.
The Bluetooth Angle Is Less Consumer Gadget Than Kernel Plumbing
Because the CVE name begins with Bluetooth, it is tempting to map it onto familiar user concerns: headphones, keyboards, pairing prompts, or nearby attackers. That framing misses the driver involved.virtio_bt is about Bluetooth over VirtIO, not the standard host controller path on a typical physical laptop.That matters for WindowsForum readers who run Linux in virtual machines, operate mixed hypervisor fleets, or maintain CI environments that boot kernels under emulation. The affected code is more relevant to guests configured with VirtIO Bluetooth support than to ordinary Bluetooth usage on bare metal. A Windows 11 laptop dual-booting Linux is not automatically in the same exposure category as a guest consuming a host-provided virtio Bluetooth backend.
Still, specialized does not mean irrelevant. Niche drivers often matter precisely because they sit in high-privilege contexts and receive complex input from unusual places. They may be less exercised by mainstream users, less visible to administrators, and less likely to be part of someone’s mental model when hardening a virtualization environment.
The practical question is therefore not “Do I use Bluetooth?” It is “Can any of my Linux guests load this driver or consume this kind of backend?” For many users, the answer will be no. For virtualization-heavy shops, it is worth checking rather than guessing.
The CVSS Silence Should Not Be Mistaken for Safety
At publication, NVD had received the CVE record but had not yet enriched it with CVSS scores or weakness classifications. That is normal in the lag between upstream disclosure and database triage. It is also a bad reason to ignore the bug.CVSS is useful as a sorting tool, but kernel vulnerabilities often arrive with incomplete scoring context. The score depends on assumptions about attacker position, required privileges, impact, and exploitability. For a VirtIO Bluetooth bug, those assumptions are especially deployment-specific.
A malicious backend in a hostile hosting environment is a different story from a benign local hypervisor on a developer workstation. A guest where the driver is unavailable is different from one where the module can be loaded. A theoretical out-of-bounds read of uninitialized receive-buffer data is different from a demonstrated privilege escalation or denial of service.
That uncertainty should lead to better triage, not complacency. The right operational stance is simple: if your kernels include the affected code and your environments expose the device path, take the stable update. If they do not, document why and move on. The absence of a neat severity badge is not a substitute for exposure analysis.
The Patch Tells Us What the Kernel Developers Feared
Security fixes often reveal their threat model in the tiny choices around the main change. Here, the patch does more than add header-length checks. It also uses rate-limited Bluetooth device error logging because the length and packet-type values come from an untrusted backend.That rate limiting is not cosmetic. If malformed packets can be generated at will, a naive error path can become a log-flooding problem. A fix that prevents a memory-safety issue should not hand the attacker an easy denial-of-service lever through system logs.
The default path for unknown packet types remains to free the socket buffer. That is also telling. The driver already knew what to do with packet types it did not recognize. The missing part was not the unknown case; it was the known-but-too-short case.
Those are often the most dangerous inputs. Code tends to defend against values outside the enum and forget that valid labels can be attached to invalid bodies. A packet that says “ACL data” but contains no ACL header is more treacherous than a packet that says nothing intelligible at all.
Stable Backports Turn a Tiny Fix Into a Fleet Problem
The CVE record references multiple stable kernel commits, which means the fix was not treated as a mainline-only cleanup. It was carried into supported stable branches. That matters because most users do not run Linus Torvalds’ current tree; they run distribution kernels, cloud images, appliance kernels, or vendor-patched long-term support releases.Backporting is where kernel security becomes operationally messy. The same logical fix may appear under different commit IDs in different stable lines. Distribution advisories may use their own package versions. Enterprise kernels may carry the patch without changing the upstream version number in a way that a casual
uname -r comparison can settle.Administrators should resist the urge to judge exposure only by upstream kernel version. The better test is whether the vendor kernel contains the virtio Bluetooth header-length validation patch. In practice, that means tracking your distribution’s security advisory, checking changelogs, or inspecting the patched source if you maintain custom kernels.
For cloud and virtualization vendors, the question cuts both ways. Guest kernels need the fix to defend themselves against malformed backend input. Host-side or service-side components that provide virtual Bluetooth devices should also be reviewed, because a security boundary that relies on “the guest will parse this sanely” is a poor boundary.
Why Windows People Should Care About a Linux Bluetooth CVE
WindowsForum is not a Linux kernel mailing list, but Windows professionals increasingly administer environments where Linux is everywhere except the desktop wallpaper. WSL, Hyper-V labs, container hosts, Kubernetes nodes, security appliances, Android build systems, and CI runners all drag Linux kernel behavior into Windows-centric shops.VirtIO itself is common in virtualization ecosystems that Windows administrators encounter indirectly, from KVM-backed infrastructure to virtual appliances shipped by vendors. Even if Hyper-V’s synthetic device model is a different stack, the security lesson transfers cleanly: virtual devices are not trusted just because they are convenient.
The Windows world has its own long history of paravirtualized drivers, guest tools, enhanced session features, clipboard sharing, file sharing, GPU virtualization, and device redirection. Each feature exists to make virtual machines feel less isolated. Each one also creates an input path that crosses a boundary users may not think about.
CVE-2026-46186 is therefore not “a Windows vulnerability,” but it is a Windows admin story. The modern Windows estate is hybrid by default. A vulnerability in a Linux guest driver can affect the reliability and isolation assumptions of the systems that Windows teams build, monitor, and patch.
The Exploitability Story Is Constrained but Not Comforting
The disclosed behavior describes an out-of-bounds read of two bytes of uninitialized receive-buffer data in a particular ACL classification path when active CIS, BIS, or PA links exist. That is narrower than arbitrary code execution. It is also not nothing.Out-of-bounds reads in the kernel can have varied consequences. Sometimes they are benign in practice. Sometimes they produce crashes, leaks, or state confusion. Sometimes they become useful only when chained with another primitive. Responsible analysis has to avoid both extremes: this is neither a proven catastrophe nor a harmless typo.
The packet-type coverage broadens the concern. The CVE description says the same hazard exists for every accepted packet type because none of the switch cases checked the payload against the fixed header size before handing it off. The highlighted ACL path is the illustrative one, not the only conceptual flaw.
That is why the fix validates all four accepted types. Security patches that close only the observed crash path often age badly. This one appears to close the class of too-short fixed-header handoffs in the driver, which is the right instinct.
The Real Pattern Is “Validated Length” Versus “Meaningful Length”
Many kernel CVEs are variations on a single argument between two interpretations of length. One layer asks whether the buffer fits inside an allocation. Another asks whether the buffer contains enough bytes for the structure being parsed. A third assumes that if the packet reached it, both earlier questions were answered.CVE-2026-46186 lives in the gap between those questions. The preceding bounds check made sure the backend did not claim a receive completion larger than the available buffer or smaller than one byte. But one byte is only enough to identify the packet type, not enough to contain the packet.
This is why fuzzers keep finding bugs in mature subsystems. They are very good at generating inputs that satisfy the first validator and violate the second parser’s expectations. Humans tend to think in terms of valid messages and invalid messages. Attackers, fuzzers, and broken devices operate in the gray middle: valid prefix, invalid body.
The most durable kernel hardening happens when developers make each layer locally skeptical. A caller should validate before calling, and a callee should avoid assuming the caller was perfect. That can feel redundant until the day a one-byte packet proves it was not.
The Fix Is Cheap; the Audit It Implies Is Not
Adding four minimum-length checks is easy. Proving that every similar receive path across every paravirtualized driver does the equivalent thing is not. That is the uncomfortable implication of this CVE.VirtIO devices often move structured data with explicit or implicit headers. Drivers may pull a type byte, inspect a length field, cast a buffer to a structure, or pass an
skb deeper into a subsystem. Each transition is a place where “some bytes arrived” must become “enough bytes arrived for what I am about to do.”The Linux kernel community has become far better at this kind of hardening, helped by sanitizers, fuzzers, static analysis, and a steady stream of stable backports. But the economics remain brutal. Every driver is a small parser. Every parser is a potential security boundary. Every security boundary is only as strong as its least glamorous length check.
For enterprises, that means the patch management answer is only part of the answer. The strategic move is reducing unnecessary virtual device exposure. If a guest does not need a virtual Bluetooth device, do not provide one. If a lab image loads modules it never uses, trim it. If a VM template enables broad device sharing for convenience, revisit the defaults.
The Vendor Database Lag Is Now Part of the Vulnerability Lifecycle
NVD’s “awaiting enrichment” state is not unusual, but it highlights a widening gap between upstream vulnerability publication and the polished metadata many organizations rely on. Kernel.org can publish a CVE with precise technical detail before NVD assigns a CVSS vector. Vendors can ship fixes before scanners agree on severity.That creates friction for teams whose patch queues are driven by dashboards. A vulnerability with no score may appear less urgent than one with a dramatic red number, even when the unscored issue is directly relevant to a production architecture. Conversely, a high score on an irrelevant component can consume attention because it looks worse in the tool.
The answer is not to abandon scoring. It is to treat scoring as the beginning of triage rather than the end. For this CVE, the decisive questions are architectural: whether Linux guests include
virtio_bt, whether a backend can feed it untrusted data, whether the affected kernel branches are deployed, and whether vendor updates have landed.That kind of triage is harder to automate, but it is exactly where experienced administrators earn their keep. A scanner can tell you a package version. It cannot always tell you whether a virtual Bluetooth backend is reachable in your threat model.
The Patch Notes Leave Administrators With a Narrow but Concrete Job
This is not a panic-and-rebuild-the-fleet vulnerability. It is a check-your-kernel-and-your-virtual-device-model vulnerability. The operational response should be boring, documented, and fast enough that the issue does not linger in forgotten VM templates.The concrete lessons are refreshingly specific:
- Systems running Linux kernels with
virtio_btsupport should receive vendor updates that include the header-length validation fix for CVE-2026-46186. - Administrators should verify exposure by looking for VirtIO Bluetooth use in guests, not by assuming that ordinary Bluetooth hardware implies the same risk.
- Virtual machine templates should avoid exposing Bluetooth or other paravirtualized devices unless the guest genuinely needs them.
- Security teams should not wait for NVD scoring before triaging kernel CVEs that include clear upstream fixes and stable backports.
- Kernel builders maintaining custom trees should confirm that event, ACL, SCO, and ISO receive paths all enforce the minimum HCI header lengths after the packet-type byte is stripped.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:02:17-07:00
NVD - CVE-2026-46186
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:02:17-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH v3 2/2] Bluetooth: virtio_bt: validate rx pkt_type header length — Linux Kernel
Linux Kernel: [PATCH v3 2/2] Bluetooth: virtio_bt: validate rx pkt_type header length
www.spinics.net
- Related coverage: kernel.googlesource.com
- Related coverage: opennet.ru
- Related coverage: lore-kernel.gnuweeb.org
- Related coverage: mail-archive.com
Re: [PATCH v3 0/2] Bluetooth: virtio_bt: harden rx against untrusted backend
www.mail-archive.com
- Related coverage: mailweb.openeuler.org
- Related coverage: security.snyk.io
Snyk Vulnerability Database | Snyk
Medium severity (4.7) Improper Handling of Length Parameter Inconsistency in kernel-headers | CVE-2026-31393
security.snyk.io
- Related coverage: lists.openwall.net
- Related coverage: support.bull.com
