CVE-2026-45836 is a newly published Linux kernel Bluetooth vulnerability, disclosed by kernel.org and added to NVD on May 26, 2026, that fixes a null-pointer dereference in the L2CAP socket callback
The fix for CVE-2026-45836 is almost aggressively unglamorous: add a NULL guard to a callback before dereferencing a socket pointer. That is the sort of patch that can disappear into a stable-kernel changelog without drama, unless it is attached to Bluetooth, kernel context, and a CVE identifier.
The affected area is L2CAP, the Logical Link Control and Adaptation Protocol layer used by Bluetooth to multiplex higher-level protocols over a Bluetooth link. In practice, L2CAP is part of the plumbing that makes Bluetooth feel ordinary: pairing, connection setup, profile behavior, and data movement all depend on stacks that must handle asynchronous events correctly.
The function named in the CVE,
Null-pointer dereferences are often treated as availability bugs rather than exploit gold. In kernel code, however, “availability” can still mean crashing the machine, panicking a device, or destabilizing a subsystem that users and administrators assume is passive until they click the Bluetooth icon. Security teams do not need every kernel CVE to be a privilege-escalation masterpiece before it deserves patch management.
CVE-2026-45836 appears in the same family of recent Linux Bluetooth L2CAP fixes that add NULL checks across callback paths. That pattern is more interesting than any single CVE. When one callback already checks for a NULL socket and another structurally similar callback does not, the problem is not just one missing
This is why fuzzers and sanitizer-driven test systems keep producing kernel crash reports from paths ordinary users never intentionally exercise. Bluetooth code receives events from devices, controllers, timers, workqueues, and socket lifecycle transitions. If a socket can disappear, detach, or fail initialization while an asynchronous callback still runs, then every callback becomes a small test of the kernel’s memory-state discipline.
The language of the CVE is restrained because the immediate defect is straightforward. But the surrounding lesson is bigger: a modern kernel is less a single program than a collection of concurrently moving promises. When one promise expires early and another piece of code still believes it is valid, a NULL pointer is often the first visible crack.
The absence of a score is not evidence of harmlessness. It means NVD has not yet completed its assessment, including vector strings and standardized severity. Kernel.org has already associated the issue with stable commits, which is the more operationally useful signal for anyone responsible for real systems.
This is where vulnerability management often goes wrong. Organizations overfit to CVSS because CVSS is machine-readable, reportable, and easy to sort. But kernel defects do not always arrive in a clean order from “most dangerous” to “least dangerous,” and a low-scored crash bug may still matter if it affects exposed appliances, kiosks, lab machines, industrial gateways, or developer laptops that run services users forgot existed.
For CVE-2026-45836, the immediate priority should be inventory and exposure, not panic. If Bluetooth is disabled at the hardware, firmware, or kernel-module level, the practical risk changes. If Bluetooth is enabled on a laptop fleet, Linux workstation pool, point-of-sale device, IoT gateway, or embedded Linux product, the fix belongs in the normal security update path.
But Windows-centric environments are rarely Windows-only anymore. Linux shows up in Hyper-V guests, WSL-backed developer workflows, container hosts, network appliances, edge devices, Android-derived systems, NAS boxes, security tools, and vendor-managed black boxes sitting on the same desks and networks as Windows PCs. A Windows admin who ignores Linux kernel CVEs because the domain controllers run Windows is managing only the visible half of the estate.
WSL itself is a special case. Typical WSL use does not expose a full Linux Bluetooth hardware stack in the same way a native Linux laptop does. But the broader point remains: developers often run Linux kernels locally, in virtualized environments, or on adjacent devices. Security teams need to know which of those kernels are vendor-serviced, which are self-managed, and which are effectively forgotten.
The same applies to dual-boot users and enthusiast machines. A Windows 11 gaming desktop that also boots Linux for tinkering is not magically risk-free because the owner spends most of the week in Windows. If the Linux side has Bluetooth enabled and is rarely patched, it can lag behind the security state of the Windows installation by months.
This matters because Linux versioning is not one straight road. Enterprise distributions backport fixes without necessarily changing to the newest upstream kernel version. Embedded vendors may carry long-term support trees with custom patches. Rolling distributions may receive the fix quickly, while appliance firmware can take weeks or months depending on the vendor.
For practical purposes, the safest path is to use the distribution or vendor’s kernel advisory mechanism rather than trying to compare upstream commit hashes by hand. On Ubuntu, Debian, Fedora, Red Hat, SUSE, Arch, Android-derived builds, appliance firmware, and embedded products, the visible kernel version may not tell the entire story. Backported patches are normal, and a kernel can be fixed without looking “new” in the simplistic version-number sense.
That is why administrators should avoid two bad instincts. The first is assuming that only the newest upstream kernel is safe. The second is assuming that an old-looking enterprise kernel is vulnerable. The only reliable answer comes from the vendor’s patched package metadata, changelog, advisory stream, or a direct inspection of the relevant source package.
A null-pointer dereference in kernel context commonly maps to denial of service, especially if an attacker can trigger the path reliably. In hardened modern kernels, NULL dereferences are usually not the easy code-execution primitive they were in older eras. The kernel should not map page zero for user-controlled execution, and mitigations have changed the exploit economics.
But “probably denial of service” is not the same as “irrelevant.” A crashable Bluetooth stack can matter on laptops, kiosks, point-of-sale terminals, medical carts, industrial tablets, and fleet-managed Linux endpoints. Availability is security when the affected device performs a business function.
The open question is triggerability. Can the path be reached by a nearby attacker over Bluetooth radio? Does it require pairing, a specific profile, a malformed connection sequence, local privileges, or a race condition produced by test harnesses? The CVE text does not answer those questions, so a responsible reading should not overclaim. The right posture is to patch promptly while resisting the temptation to invent an exploit narrative not present in the record.
That is common in large C codebases. Defensive checks accrete around known-dangerous paths, but similar functions do not always get updated at the same time. Over years, one callback becomes cautious, another remains optimistic, and a fuzzer eventually finds the gap.
In a memory-safe language debate, this kind of bug is often used as a blunt argument against C. That argument has force, but the kernel reality is more complicated. Linux is not going to become entirely memory-safe overnight, and Bluetooth controller interactions, driver boundaries, and protocol state machines will remain complex even as Rust enters selected kernel areas.
The near-term work is less glamorous: audit related callbacks, make lifecycle assumptions explicit, add tests, backport fixes, and shrink the conditions under which asynchronous work can outlive the object it expects. CVE-2026-45836 looks like exactly that kind of maintenance. It is not flashy, but it is the work that keeps kernels from turning edge cases into field failures.
A headless cloud VM running a general-purpose Linux kernel usually has no Bluetooth controller, no radio proximity exposure, and no reason to load the Bluetooth stack. A Linux laptop used by a developer in an open office is different. A ruggedized tablet in a warehouse, a kiosk with wireless peripherals, or an embedded gateway with Bluetooth provisioning support is different again.
Administrators should also remember that Bluetooth can be present even when nobody thinks of the device as “using Bluetooth.” Some systems include combo Wi-Fi/Bluetooth chipsets by default. Some appliances expose Bluetooth only during setup. Some lab systems enable it because the base image did, not because the workload needs it.
The best mitigation, after patching, is reducing needless attack surface. If Bluetooth is not required, disable it at the service, kernel module, firmware, BIOS/UEFI, or device-management layer appropriate to the platform. Patch management is better when paired with configuration management; otherwise the same dormant subsystem will keep generating emergency work every time another CVE appears.
This is a familiar pattern in kernel security. One bug report forces developers to inspect similar code paths. A patch lands for one callback, then another, then another. CVEs appear as individual entries because vulnerability tracking prefers discrete records, even when the engineering story is one broader audit.
For defenders, clusters matter because they reveal where the subsystem has been under active stress. A run of L2CAP fixes means Bluetooth should be on the near-term watchlist for Linux endpoint and embedded-device patching. It does not mean every machine is in danger, but it does mean the lazy assumption that Bluetooth is a solved commodity stack is wrong.
The irony is that users experience Bluetooth as either “my headphones connect” or “my headphones do not connect.” Underneath that binary experience is a stack of protocol negotiation, security confirmation, socket state, workqueues, timeout callbacks, and device events. CVE-2026-45836 lives in that hidden machinery.
For mainstream Linux distributions, the update may arrive through ordinary security channels. For enterprise Linux, the fix may be backported into older supported kernel streams. For embedded products, the timing depends on vendors whose update habits vary wildly. For devices that are technically Linux but operationally invisible to IT, the fix may never arrive unless someone asks the vendor.
This is one reason Windows administrators should care. Windows estates increasingly rely on Linux-based supporting infrastructure: VPN appliances, monitoring probes, build agents, NAS units, backup appliances, conference-room systems, and edge gateways. A vulnerability in Linux Bluetooth may not affect a Windows desktop, but it can affect the device that provisions badges, scans inventory, or bridges sensors into the network.
The responsible question for vendors is direct: is the product affected by CVE-2026-45836, and if so, which firmware or kernel build includes the fix? A vague statement that “we monitor CVEs” is not enough. Customers should ask for the fixed build, the affected version range, and whether Bluetooth can be disabled safely if it is not needed.
But localized risk is still risk. Bluetooth attacks are often proximity-bound, which makes them easy to dismiss in cloud-first threat models. Yet proximity is not rare for laptops, offices, campuses, airports, hospitals, retail floors, factories, and classrooms. The attacker does not need to be on the other side of the planet if the vulnerable device is in a public or semi-public physical environment.
Security operations teams should therefore avoid both extremes. Do not sound the siren as though every Linux host is remotely exploitable from the internet. Do not bury the CVE simply because NVD has not scored it yet. Treat it as a kernel Bluetooth hardening issue that deserves normal security-update urgency, especially for devices where Bluetooth is enabled and uptime matters.
The most mature response is boring by design: verify exposure, patch through vendor channels, disable unused Bluetooth, and track downstream advisories. That approach will handle CVE-2026-45836 and the next L2CAP null-pointer CVE without turning every small kernel callback fix into a bespoke crisis.
l2cap_sock_get_sndtimeo_cb(). The important part is not that this is a spectacular remote-code-execution bug; it is that the Bluetooth stack is again showing how small callback assumptions can become security-tracked kernel defects. For WindowsForum readers, the story is less “patch one CVE” than “understand where Linux-powered endpoints, appliances, containers, and embedded systems quietly sit inside a Windows-heavy estate.” This is the kind of kernel bug that looks minor until it appears in a fleet nobody remembered had Bluetooth enabled.
A One-Line Guard Becomes a Security Event
The fix for CVE-2026-45836 is almost aggressively unglamorous: add a NULL guard to a callback before dereferencing a socket pointer. That is the sort of patch that can disappear into a stable-kernel changelog without drama, unless it is attached to Bluetooth, kernel context, and a CVE identifier.The affected area is L2CAP, the Logical Link Control and Adaptation Protocol layer used by Bluetooth to multiplex higher-level protocols over a Bluetooth link. In practice, L2CAP is part of the plumbing that makes Bluetooth feel ordinary: pairing, connection setup, profile behavior, and data movement all depend on stacks that must handle asynchronous events correctly.
The function named in the CVE,
l2cap_sock_get_sndtimeo_cb(), suggests the failure point lives in a socket callback path that retrieves send-timeout state. The kernel.org description says the fix adds the same NULL guard already present in two neighboring callbacks, l2cap_sock_resume_cb() and l2cap_sock_ready_cb(). That detail matters because it tells us this was not a new design concept; it was an inconsistency in defensive programming across similar callback paths.Null-pointer dereferences are often treated as availability bugs rather than exploit gold. In kernel code, however, “availability” can still mean crashing the machine, panicking a device, or destabilizing a subsystem that users and administrators assume is passive until they click the Bluetooth icon. Security teams do not need every kernel CVE to be a privilege-escalation masterpiece before it deserves patch management.
Bluetooth Keeps Finding the Sharp Edges in Kernel State
Bluetooth has always been a deceptively messy attack surface. It is radio-facing, stateful, profile-heavy, and full of transitions: discovery, pairing, authentication, connection negotiation, timeout handling, disconnection, reconnection, and error recovery. The bugs rarely look cinematic in isolation, but the stack’s complexity creates many opportunities for stale assumptions.CVE-2026-45836 appears in the same family of recent Linux Bluetooth L2CAP fixes that add NULL checks across callback paths. That pattern is more interesting than any single CVE. When one callback already checks for a NULL socket and another structurally similar callback does not, the problem is not just one missing
if; it is a mismatch between what the code’s lifecycle allows and what the code’s authors expected.This is why fuzzers and sanitizer-driven test systems keep producing kernel crash reports from paths ordinary users never intentionally exercise. Bluetooth code receives events from devices, controllers, timers, workqueues, and socket lifecycle transitions. If a socket can disappear, detach, or fail initialization while an asynchronous callback still runs, then every callback becomes a small test of the kernel’s memory-state discipline.
The language of the CVE is restrained because the immediate defect is straightforward. But the surrounding lesson is bigger: a modern kernel is less a single program than a collection of concurrently moving promises. When one promise expires early and another piece of code still believes it is valid, a NULL pointer is often the first visible crack.
NVD Has Not Scored It, but Administrators Should Not Wait for the Number
At publication, NVD lists CVE-2026-45836 as awaiting enrichment, with no CVSS v4.0, v3.x, or v2.0 score from NIST. That leaves defenders in the familiar awkward zone between “there is a CVE” and “there is a neat severity badge for the dashboard.” For Linux kernel vulnerabilities, this gap is common enough that mature teams should plan around it rather than be surprised by it.The absence of a score is not evidence of harmlessness. It means NVD has not yet completed its assessment, including vector strings and standardized severity. Kernel.org has already associated the issue with stable commits, which is the more operationally useful signal for anyone responsible for real systems.
This is where vulnerability management often goes wrong. Organizations overfit to CVSS because CVSS is machine-readable, reportable, and easy to sort. But kernel defects do not always arrive in a clean order from “most dangerous” to “least dangerous,” and a low-scored crash bug may still matter if it affects exposed appliances, kiosks, lab machines, industrial gateways, or developer laptops that run services users forgot existed.
For CVE-2026-45836, the immediate priority should be inventory and exposure, not panic. If Bluetooth is disabled at the hardware, firmware, or kernel-module level, the practical risk changes. If Bluetooth is enabled on a laptop fleet, Linux workstation pool, point-of-sale device, IoT gateway, or embedded Linux product, the fix belongs in the normal security update path.
The Windows Angle Is Not Windows Itself
CVE-2026-45836 is not a Windows kernel vulnerability. That distinction should be clear. The bug is in the Linux kernel’s Bluetooth stack, and Microsoft’s Windows Bluetooth stack is not implicated by the Linux L2CAP callback named in this CVE.But Windows-centric environments are rarely Windows-only anymore. Linux shows up in Hyper-V guests, WSL-backed developer workflows, container hosts, network appliances, edge devices, Android-derived systems, NAS boxes, security tools, and vendor-managed black boxes sitting on the same desks and networks as Windows PCs. A Windows admin who ignores Linux kernel CVEs because the domain controllers run Windows is managing only the visible half of the estate.
WSL itself is a special case. Typical WSL use does not expose a full Linux Bluetooth hardware stack in the same way a native Linux laptop does. But the broader point remains: developers often run Linux kernels locally, in virtualized environments, or on adjacent devices. Security teams need to know which of those kernels are vendor-serviced, which are self-managed, and which are effectively forgotten.
The same applies to dual-boot users and enthusiast machines. A Windows 11 gaming desktop that also boots Linux for tinkering is not magically risk-free because the owner spends most of the week in Windows. If the Linux side has Bluetooth enabled and is rarely patched, it can lag behind the security state of the Windows installation by months.
Stable Kernel Fixes Are the Real Clock
The CVE record references multiple stable-kernel commits, which indicates the fix is being carried across supported kernel lines rather than left only in a development branch. That is what Linux administrators should watch. The question is not “does CVE-2026-45836 exist?” but “has the kernel I actually boot include the relevant stable fix?”This matters because Linux versioning is not one straight road. Enterprise distributions backport fixes without necessarily changing to the newest upstream kernel version. Embedded vendors may carry long-term support trees with custom patches. Rolling distributions may receive the fix quickly, while appliance firmware can take weeks or months depending on the vendor.
For practical purposes, the safest path is to use the distribution or vendor’s kernel advisory mechanism rather than trying to compare upstream commit hashes by hand. On Ubuntu, Debian, Fedora, Red Hat, SUSE, Arch, Android-derived builds, appliance firmware, and embedded products, the visible kernel version may not tell the entire story. Backported patches are normal, and a kernel can be fixed without looking “new” in the simplistic version-number sense.
That is why administrators should avoid two bad instincts. The first is assuming that only the newest upstream kernel is safe. The second is assuming that an old-looking enterprise kernel is vulnerable. The only reliable answer comes from the vendor’s patched package metadata, changelog, advisory stream, or a direct inspection of the relevant source package.
The Exploit Story Is Still Thin
The public description of CVE-2026-45836 does not, by itself, establish a working exploit, a privilege-escalation chain, or a remote unauthenticated attack scenario. It identifies a resolved kernel bug: a null-pointer dereference in a Bluetooth L2CAP callback, fixed by adding a guard already used in related callbacks. That should shape the response.A null-pointer dereference in kernel context commonly maps to denial of service, especially if an attacker can trigger the path reliably. In hardened modern kernels, NULL dereferences are usually not the easy code-execution primitive they were in older eras. The kernel should not map page zero for user-controlled execution, and mitigations have changed the exploit economics.
But “probably denial of service” is not the same as “irrelevant.” A crashable Bluetooth stack can matter on laptops, kiosks, point-of-sale terminals, medical carts, industrial tablets, and fleet-managed Linux endpoints. Availability is security when the affected device performs a business function.
The open question is triggerability. Can the path be reached by a nearby attacker over Bluetooth radio? Does it require pairing, a specific profile, a malformed connection sequence, local privileges, or a race condition produced by test harnesses? The CVE text does not answer those questions, so a responsible reading should not overclaim. The right posture is to patch promptly while resisting the temptation to invent an exploit narrative not present in the record.
The Bug Is Small Because the State Machine Is Big
The most revealing phrase in the CVE description is “Add the same NULL guard already present” elsewhere. It implies the maintainers already understood that some L2CAP socket callbacks can receive a NULL pointer. The defect was that this understanding was not uniformly encoded.That is common in large C codebases. Defensive checks accrete around known-dangerous paths, but similar functions do not always get updated at the same time. Over years, one callback becomes cautious, another remains optimistic, and a fuzzer eventually finds the gap.
In a memory-safe language debate, this kind of bug is often used as a blunt argument against C. That argument has force, but the kernel reality is more complicated. Linux is not going to become entirely memory-safe overnight, and Bluetooth controller interactions, driver boundaries, and protocol state machines will remain complex even as Rust enters selected kernel areas.
The near-term work is less glamorous: audit related callbacks, make lifecycle assumptions explicit, add tests, backport fixes, and shrink the conditions under which asynchronous work can outlive the object it expects. CVE-2026-45836 looks like exactly that kind of maintenance. It is not flashy, but it is the work that keeps kernels from turning edge cases into field failures.
Patch Triage Starts With Bluetooth Reality, Not Asset Counts
The fastest way to mismanage this CVE is to ask, “How many Linux machines do we have?” The better question is, “Which Linux kernels in our environment have Bluetooth enabled, reachable, and business-relevant?” Those are not the same inventory.A headless cloud VM running a general-purpose Linux kernel usually has no Bluetooth controller, no radio proximity exposure, and no reason to load the Bluetooth stack. A Linux laptop used by a developer in an open office is different. A ruggedized tablet in a warehouse, a kiosk with wireless peripherals, or an embedded gateway with Bluetooth provisioning support is different again.
Administrators should also remember that Bluetooth can be present even when nobody thinks of the device as “using Bluetooth.” Some systems include combo Wi-Fi/Bluetooth chipsets by default. Some appliances expose Bluetooth only during setup. Some lab systems enable it because the base image did, not because the workload needs it.
The best mitigation, after patching, is reducing needless attack surface. If Bluetooth is not required, disable it at the service, kernel module, firmware, BIOS/UEFI, or device-management layer appropriate to the platform. Patch management is better when paired with configuration management; otherwise the same dormant subsystem will keep generating emergency work every time another CVE appears.
Security Teams Should Treat This as a Signal Cluster
CVE-2026-45836 should not be read in isolation. Recent Linux Bluetooth L2CAP entries have described similar NULL guard fixes in neighboring callbacks, including callback names for ready, resume, new connection, state change, and send-timeout behavior. That cluster suggests maintainers are hardening a set of related lifecycle edges rather than fixing one random typo.This is a familiar pattern in kernel security. One bug report forces developers to inspect similar code paths. A patch lands for one callback, then another, then another. CVEs appear as individual entries because vulnerability tracking prefers discrete records, even when the engineering story is one broader audit.
For defenders, clusters matter because they reveal where the subsystem has been under active stress. A run of L2CAP fixes means Bluetooth should be on the near-term watchlist for Linux endpoint and embedded-device patching. It does not mean every machine is in danger, but it does mean the lazy assumption that Bluetooth is a solved commodity stack is wrong.
The irony is that users experience Bluetooth as either “my headphones connect” or “my headphones do not connect.” Underneath that binary experience is a stack of protocol negotiation, security confirmation, socket state, workqueues, timeout callbacks, and device events. CVE-2026-45836 lives in that hidden machinery.
Vendors Will Decide When Most Users Are Actually Fixed
Kernel.org can publish a fix quickly, but most users do not run kernels directly from kernel.org. They run distribution kernels, Android vendor kernels, appliance firmware, or enterprise builds maintained under support contracts. That means the practical remediation timeline is downstream.For mainstream Linux distributions, the update may arrive through ordinary security channels. For enterprise Linux, the fix may be backported into older supported kernel streams. For embedded products, the timing depends on vendors whose update habits vary wildly. For devices that are technically Linux but operationally invisible to IT, the fix may never arrive unless someone asks the vendor.
This is one reason Windows administrators should care. Windows estates increasingly rely on Linux-based supporting infrastructure: VPN appliances, monitoring probes, build agents, NAS units, backup appliances, conference-room systems, and edge gateways. A vulnerability in Linux Bluetooth may not affect a Windows desktop, but it can affect the device that provisions badges, scans inventory, or bridges sensors into the network.
The responsible question for vendors is direct: is the product affected by CVE-2026-45836, and if so, which firmware or kernel build includes the fix? A vague statement that “we monitor CVEs” is not enough. Customers should ask for the fixed build, the affected version range, and whether Bluetooth can be disabled safely if it is not needed.
The Practical Risk Is Localized, but the Lesson Is Broad
There is no reason to treat CVE-2026-45836 as an internet-scale emergency on the available information. It is not a remotely reachable OpenSSH flaw, not a wormable SMB bug, and not a browser zero-day under active exploitation. Its likely impact is narrower, tied to Bluetooth exposure and affected Linux kernel builds.But localized risk is still risk. Bluetooth attacks are often proximity-bound, which makes them easy to dismiss in cloud-first threat models. Yet proximity is not rare for laptops, offices, campuses, airports, hospitals, retail floors, factories, and classrooms. The attacker does not need to be on the other side of the planet if the vulnerable device is in a public or semi-public physical environment.
Security operations teams should therefore avoid both extremes. Do not sound the siren as though every Linux host is remotely exploitable from the internet. Do not bury the CVE simply because NVD has not scored it yet. Treat it as a kernel Bluetooth hardening issue that deserves normal security-update urgency, especially for devices where Bluetooth is enabled and uptime matters.
The most mature response is boring by design: verify exposure, patch through vendor channels, disable unused Bluetooth, and track downstream advisories. That approach will handle CVE-2026-45836 and the next L2CAP null-pointer CVE without turning every small kernel callback fix into a bespoke crisis.
The Small Patch That Should Change the Checklist
CVE-2026-45836 is a useful reminder that vulnerability management is not only about severity labels; it is about knowing which subsystems are actually alive in your environment. The concrete response is short, but it should be applied with discipline.- Administrators should identify Linux systems and embedded devices where Bluetooth is enabled, especially laptops, kiosks, gateways, and appliances in physically accessible locations.
- Patch decisions should follow distribution and vendor advisories rather than upstream version-number guessing, because many vendors backport kernel fixes.
- Systems that do not need Bluetooth should have it disabled through durable configuration controls, not merely ignored in the user interface.
- Security teams should monitor related Linux Bluetooth L2CAP fixes as a cluster, because repeated NULL-guard patches suggest active hardening of the same subsystem.
- Windows-focused environments should include Linux-based appliances, developer machines, WSL-adjacent workflows, and dual-boot systems in their exposure review.
- The lack of an NVD CVSS score on May 26, 2026, should not delay routine kernel patching where affected Bluetooth functionality is present.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:05:55-07:00
NVD - CVE-2026-45836
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:05:55-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: windowsforum.com
CVE-2026-31510 Linux Bluetooth Fix: Prevent Null Deref in L2CAP
Linux has published another Bluetooth kernel fix that looks small on the surface but matters for anyone tracking availability and stability risks in the network stack. CVE-2026-31510 covers a null-pointer dereference in l2cap_sock_ready_cb, where the kernel now checks whether the sk pointer is...
windowsforum.com
- Related coverage: spinics.net
RE: [v3] Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb() — Linux Bluetooth
Linux Bluetooth: RE: [v3] Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_get_sndtimeo_cb()www.spinics.net - Related coverage: cve.imfht.com
CVE-2026-31512: Linux kernel 安全漏洞
## 概述 Linux 内核蓝牙协议栈的 `l2cap_ecred_data_rcv()` 函数在读取 SDU 长度字段前未验证 skb 数据长度，导致在 skb 长度不足时读取越界。该问题已在修复中通过增加长度校验解决。 ## 影响版本 未明确列出具体版本范围，但涉及存在此代码的 Linux 内核版本。 ## 细节 - 函数 `l2cap_ecred_data_rcv()` 直接
cve.imfht.com
- Related coverage: vuldb.com
CVE-2026-31510 Linux Kernel Bluetooth l2cap_sock_ready_cb null pointer dereference
A vulnerability was identified in Linux Kernel up to 6.19.10. This vulnerability is referenced as CVE-2026-31510. Upgrading the affected component is recommended.
vuldb.com
- Related coverage: cvefeed.io
CVE-2026-31510 - Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb Before using sk pointer, check if it is null. Fix the following: KASAN: null-ptr-deref in range [0x0000000000000260-0x0000000000000267] CPU: 0 UID: 0 PID: 5985 Comm...cvefeed.io
- Related coverage: support.bull.com
