CVE-2026-98108

Executive Summary

CVE-2026-98108 is a vulnerability in the Linux kernel Bluetooth L2CAP subsystem. The l2cap_le_connect_req() function fails to set the correct logical channel mode, causing channels in FLAG_DEFER_SETUP state to incorrectly respond to LE Connection Requests with L2CAP_ECRED_CONN_RSP. This mismatch enables an out-of-bounds (OOB) write of attacker-influenced values in l2cap_ecred_rsp_defer(), because the number of deferred channels is not bounded and duplicate identifiers are not validated. Systems running affected Linux kernels with Bluetooth LE enabled and reachable by an adjacent wireless attacker are in scope. No public proof-of-concept, exploit code, or vendor patch currently exists for this CVE.

Technical Analysis

The Linux Bluetooth L2CAP layer implements connection-oriented channels (CoC) for LE devices. The relevant flow is:

• l2cap_new_connection() initializes a new channel and sets its default mode to match the parent (listening) channel.
• l2cap_le_connect_req() handles incoming LE Connection Requests. In the vulnerable version, it leaves the channel mode at this inherited default instead of explicitly assigning the correct value. As a result, if the listening parent channel is in L2CAP_MODE_EXT_FLOWCTL (Enhanced Credit Based Flow Control), newly created channels are also placed in that mode.
• Channels with FLAG_DEFER_SETUP set should not immediately accept the connection; instead, the stack signals the userspace socket to make an authorization decision. However, because the mode was incorrectly inherited, the kernel responds to a L2CAP_LE_CONN_REQ with an L2CAP_ECRED_CONN_RSP (Enhanced Credit Based Connection Response) instead of deferring via the normal authorization path. This response is semantically incorrect for deferred channels.

The security impact arises in l2cap_ecred_rsp_defer(). This function is invoked to defer channels pending userspace acceptance. The vulnerable code:

• Does not limit the maximum number of deferred channels that may accumulate, and
• Does not check for duplicate identifier values in the L2CAP_ECRED_CONN_REQ.

Because l2cap_alloc_cid() allocates CIDs and derives certain values from them, an attacker able to queue a large number of deferred channels — or to reuse identifiers — can cause an out-of-bounds write into an internal data structure used by l2cap_ecred_rsp_defer(). The OOB write is described as writing values determined by l2cap_alloc_cid(), i.e., attacker-influenced in magnitude by control over how many and which CIDs are allocated.

The fix described in the NVD entry does two things:

1. Set chan->mode correctly inside l2cap_le_connect_req() so that deferred channels no longer inherit EXT_FLOWCTL incorrectly.
2. Add a channel mode check in l2cap_ecred_rsp_defer() and replace the OOB write with WARN_ON_ONCE, converting a memory-safety bug into a diagnostic warning to reduce brittleness.

Attack surface: The flaw is reachable over the Bluetooth LE air interface. An attacker must be within Bluetooth radio range (typically ~10–100 m depending on class and antenna) and must be able to initiate an L2CAP LE connection to a vulnerable target. No authentication is required at the L2CAP layer prior to the authorization decision, since the bug specifically concerns the pre-authorization handling of deferred channels.

Affected component: Linux kernel Bluetooth L2CAP (net/bluetooth/l2cap_core.c contains the referenced functions; the NVD description does not explicitly state the file path, so this is indicated as the known upstream location for these symbol names).

No affected version ranges, OSV package entries, or CWE assignments were provided in the source data; the vulnerability class is consistent with an out-of-bounds write caused by missing bounds and duplicate-input validation.

Exploitation Scenarios

No public PoC or exploit code exists for CVE-2026-98108; the chain below is inferred from the vulnerability class and the NVD description. No specific packet formats beyond those named in the description (L2CAP_LE_CONN_REQ, L2CAP_ECRED_CONN_RSP) are assumed.

1. Reconnaissance / target identification. An attacker within Bluetooth LE radio range scans for advertising devices. Devices that expose LE L2CAP connection-oriented channels (for example, peripherals offering LE CoC services) are candidate targets. The attacker identifies a peer whose listening L2CAP channel is configured in L2CAP_MODE_EXT_FLOWCTL (or can induce such a configuration). No credentials or pairing are required at the L2CAP layer for the initial request.

2. Triggering the flaw. The attacker sends an L2CAP_LE_CONN_REQ to the target's listening channel. Because l2cap_le_connect_req() leaves the new channel mode at the inherited default, the newly created channel is placed in EXT_FLOWCTL mode even though it carries FLAG_DEFER_SETUP. The kernel therefore emits an L2CAP_ECRED_CONN_RSP rather than holding the channel for userspace authorization. This provides the attacker a foothold to enqueue deferred channels on the EXT_FLOWCTL path.

3. Payload / execution method (vulnerability-class level). The attacker repeats or manipulates L2CAP_LE_CONN_REQ submissions so that deferred channels accumulate. Because l2cap_ecred_rsp_defer() neither caps the number of deferred channels nor detects duplicate identifiers, the internal bookkeeping used to allocate CIDs and compute associated values is driven out of bounds. The write is of values derived from l2cap_alloc_cid() — i.e., the attacker influences the length/index domain rather than supplying a fully arbitrary payload. This is a memory-corruption primitive, not a direct code-execution technique; converting it to control-flow hijack would require additional primitives (heap grooming, defeating mitigations such as KASLR and stack canaries), which are not described in the available data.

4. Post-exploitation impact. Successful OOB write in kernel context on a Bluetooth-reachable device can lead to kernel panic (denial of service), memory corruption, and — if the attacker can shape adjacent memory — escalation to kernel code execution and full device compromise. In embedded or mobile targets, this may bypass application sandboxing entirely because the corruption occurs in kernel space. The exact post-exploitation outcome depends on allocator behavior and target kernel configuration, neither of which is specified in the source data.

Impact Assessment

• Confidentiality: Not directly affected by the described OOB write; no information disclosure primitive is stated. (If CVSS subscores were available, confidentiality would likely be Low/None; the source data provides no CVSS values.)
• Integrity: High potential — kernel memory corruption permits modification of kernel data structures if the OOB write reaches adjacent controlled allocations.
• Availability: High — OOB writes in kernel context can reliably crash the system (kernel panic / BUG), and the WARN_ON_ONCE conversion in the fix indicates the original path could corrupt state rather than cleanly abort.
• Scope: Unchanged — the vulnerability is contained within the Bluetooth/L2CAP kernel subsystem, though the impact on a fully compromised kernel is device-wide.

Business impact: Any Linux-based device with Bluetooth LE and LE CoC / Enhanced Credit Based Flow Control in use is potentially affected — including mobile devices, IoT/embedded products, automotive head units, and Linux desktops/laptops. The proximity requirement (adjacent wireless attacker) limits mass-exploitation potential but makes the issue relevant for high-value targeted environments (air-gapped facilities, kiosks, medical devices, industrial controllers with Bluetooth). Because no patch is available (patch confidence 0/4), the exposure window remains open until upstream fixes and stable backports are applied. Absence from CISA KEV and lack of public exploits indicate no known in-the-wild exploitation at the time of writing.

Blast radius: The L2CAP and Bluetooth core are shared kernel code; a working exploit against one kernel version may be portable across many distributions sharing the same subsystem. Backported vendor kernels require separate assessment because the referenced functions and their behavior may differ from mainline.

Detection Guidance

Detection for this class of bug is difficult because the exploit occurs over the Bluetooth air interface, not IP. Host-based detection should focus on anomalous L2CAP/Bluetooth stack behavior (kernel warnings, crashes, unexpected BT socket activity), while network detection is limited to environments that capture Bluetooth traffic (e.g., HCI snoop logs).

Sigma Rule

title: Linux Kernel Bluetooth L2CAP ECRED Deferred Channel Abuse (CVE-2026-98108)
id: 8f0a3c2e-5b6d-4e1a-9c7f-2d1e6a4b0c33
status: experimental
description: Detects kernel messages consistent with Bluetooth L2CAP EXT_FLOWCTL deferred channel mishandling and the WARN_ON_ONCE converted from an out-of-bounds write.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-98108
author: valtersit.com
logsource:
  product: linux
  service: kernel
detection:
  keywords_l2cap:
    - 'l2cap_ecred_rsp_defer'
    - 'l2cap_le_connect_req'
    - 'L2CAP_ECRED_CONN_RSP'
  keywords_warn:
    - 'WARNING: CPU'
    - 'WARN_ON_ONCE'
  keywords_bt:
    - 'Bluetooth: L2CAP'
    - 'EXT_FLOWCTL'
  condition: (keywords_l2cap and keywords_warn) or (keywords_bt and keywords_warn)
falsepositives:
  - Legitimate kernel warnings from unrelated Bluetooth development/testing
level: medium

YARA Rule

rule CVE_2026_98108_L2CAP_ECRED_DEFER
{
    meta:
        description = "Detects Linux kernel builds containing L2CAP ECRED deferred channel handling related to CVE-2026-98108"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-98108"
        author = "valtersit.com"
        date = "2026-06-01"

    strings:
        $fn1 = "l2cap_le_connect_req" ascii
        $fn2 = "l2cap_ecred_rsp_defer" ascii
        $fn3 = "l2cap_alloc_cid" ascii
        $mode = "L2CAP_MODE_EXT_FLOWCTL" ascii
        $flag = "FLAG_DEFER_SETUP" ascii

    condition:
        uint32(0) == 0x464c457f and 3 of ($fn*) and ($mode or $flag)
}

Suricata IDS Rule

Note: L2CAP runs below IP and is not visible to standard Suricata on an IP interface. The rule below targets environments that tunnel or mirror HCI/L2CAP captures over a DLT user link; it is provided as a best-effort signature and should be calibrated to the local capture setup.

alert ip any any -> any any (msg:"CVE-2026-98108 Linux Bluetooth L2CAP ECRED deferred channel abuse (EXT_FLOWCTL)"; content:"|05 00 01 00|"; byte_test:1,>,0,0; flow:stateless; threshold:type both, track by_src, count 20, seconds 10; metadata:cve CVE-2026-98108; classtype:attempted-admin; sid:202698108; rev:1;)

Elastic Detection

process where event.category == "process" and event.action == "started" and
  process.name in ("dmesg", "journalctl", "klogd", "rsyslogd") and
  process.command_line in~ ("*l2cap_ecred_rsp_defer*", "*l2cap_le_connect_req*", "*L2CAP_ECRED_CONN_RSP*")

Splunk SPL Query

index=* (source=syslog OR source=linux_secure OR source=osquery) ("l2cap_ecred_rsp_defer" OR "l2cap_le_connect_req" OR "L2CAP_ECRED_CONN_RSP" OR "EXT_FLOWCTL" OR "FLAG_DEFER_SETUP")
| stats count min(_time) as first_seen max(_time) as last_seen values(host) as hosts by host, message
| where count > 0
| convert ctime(first_seen) ctime(last_seen)

Wazuh OSSEC Rule

<group name="linux,cve,bluetooth,">
  <rule id="981081" level="10">
    <decoded_as>syslog</decoded_as>
    <match>l2cap_ecred_rsp_defer|l2cap_le_connect_req|L2CAP_ECRED_CONN_RSP|L2CAP_MODE_EXT_FLOWCTL</match>
    <description>CVE-2026-98108: Linux kernel Bluetooth L2CAP EXT_FLOWCTL deferred channel handling activity detected</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <rule id="981082" level="12">
    <if_sid>981081</if_sid>
    <match>WARN_ON_ONCE|WARNING: CPU|out-of-bounds|KASAN|BUG:</match>
    <description>CVE-2026-98108: Possible exploitation - kernel warning/OOB during L2CAP ECRED deferred handling</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations (no upstream fix identified):

   • Disable Bluetooth on any system that does not require it: systemctl stop bluetooth && systemctl disable bluetooth, or blacklist the Bluetooth kernel modules (rfkill block bluetooth, module blacklist for bluetooth, btusb).
   • On systems requiring Bluetooth, restrict exposure: disable Bluetooth LE advertising/broadcasting where the use case permits, and reduce discoverability to minimize the set of nearby devices able to initiate LE connections.
   • Enforce physical/radio controls during sensitive operations (RF shielding, restricted areas) since the attack requires an adjacent Bluetooth attacker.
   • Enable kernel hardening observability (KASAN on development/test kernels, panic_on_warn in high-assurance environments) to detect the WARN_ON_ONCE condition introduced by the upstream fix path when backported, and to catch related OOB activity early.
   • Monitor kernel logs (dmesg, journald) for Bluetooth/L2CAP anomalies and unexpected stack traces.

2. Patch/upgrade steps (when available):

   • Monitor the Linux kernel stable and long-term branches and vendor advisories for a fix that sets chan->mode in l2cap_le_connect_req(), adds a channel mode check in l2cap_ecred_rsp_defer(), and replaces the OOB write with WARN_ON_ONCE.
   • Once the upstream commit is published, apply it to mainline and request/confirm backports from your distribution (Ubuntu, RHEL, SUSE, Debian, Android common kernels) and embedded vendor BSPs.
   • Validate that the installed kernel build includes the fix before re-enabling Bluetooth on affected hosts.

3. Long-term hardening:

   • Enforce a governed Bluetooth exposure policy (allow-listing, default-off on servers and non-peripheral systems).
   • Maintain a patch management process that covers kernel Bluetooth subsystems in IoT/embedded fleets, which are frequently overlooked.
   • Fuzz and test L2CAP Enhanced Credit Based Flow Control and deferred-channel authorization paths in vendor QA to catch missing bounds/duplicate checks before release.
   • Instrument production kernels for kernel warning telemetry and ship it into the SIEM to detect early exploitation attempts of memory-safety bugs in the Bluetooth stack.

References

• NVD — CVE-2026-98108: https://nvd.nist.gov/vuln/detail/CVE-2026-98108
• Linux Kernel Mailing List / Bluetooth subsystem patchwork (monitor for the upstream fix "Bluetooth: L2CAP: fix chan mode for LE_CONN_REQ + EXT_FLOWCTL pchan"): https://lore.kernel.org/linux-bluetooth/
• Linux kernel stable tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
• CISA Known Exploited Vulnerabilities Catalog (currently NOT listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• FIRST EPSS (no score assigned at time of writing): https://www.first.org/epss/

No public PoC, exploit code, or exploit-in-the-wild evidence was identified in the source data. No threat actor campaigns are associated with this CVE at the time of writing. CVSS score and vector were not provided by the source; the vector shown in METADATA is an analytical estimate based on the described mechanism (adjacent attack vector, no privileges, high availability and potential integrity impact) and should be treated as provisional until an official score is published.