CVE-2026-31498

What it actually does

This flaw affects the Linux kernel Bluetooth L2CAP implementation, specifically Enhanced Retransmission Mode (ERTM) channel reconfiguration. A crafted L2CAP configuration request sent after a channel is already connected can cause the kernel to reinitialize ERTM queues and lists without freeing the prior allocations, leaking kernel memory. Separately, a malformed RFC max_pdu_size option can set the remote maximum PDU size to zero; when the kernel later segments an SDU, the computed PDU length remains zero, causing a non-terminating loop that continuously consumes memory. The practical impact is local denial of service through kernel memory exhaustion, OOM activity, service disruption, or system instability. The provided CVSS vector indicates local access with low privileges is required, and there is no indication of confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make Linux systems with exposed or usable Bluetooth functionality unstable or unavailable, potentially causing outages for endpoints, embedded devices, kiosks, industrial systems, or appliances that rely on Bluetooth. Because this is not listed in CISA KEV, has very low EPSS, no known ransomware association, and no reported exploit maturity, broad active exploitation appears unlikely at this time; however, systems where untrusted users or Bluetooth peers can interact with the stack should still be patched because the consequence is high availability impact.

How an attack unfolds

An attacker first obtains the ability to interact with the vulnerable host’s Bluetooth L2CAP stack, such as through local low-privileged access to Bluetooth functionality or control of a Bluetooth peer/channel permitted to negotiate L2CAP parameters. The attacker establishes an L2CAP ERTM channel and drives it into the connected state through normal configuration. After the channel is connected, the attacker sends a crafted CONFIG_REQ that triggers the reconfiguration path. Because the vulnerable kernel incorrectly treats the already-connected channel as if ERTM initialization should run again, it reinitializes internal transmit, selective reject, and retransmission data structures without releasing the prior allocations, leaking memory. The attacker can repeat this behavior to steadily consume kernel memory. In the second path, the attacker supplies a malformed max_pdu_size value that results in a zero remote_mps; when data is segmented, pdu_len becomes zero and the segmentation loop never makes progress, causing uncontrolled memory consumption. Eventually the system may invoke the OOM killer, terminate critical processes, degrade Bluetooth/network functionality, or become unresponsive.

How to fix it

Upgrade to a Linux kernel version that includes the upstream Bluetooth L2CAP fix for ERTM reinitialization and zero pdu_len handling. No exact fixed versions were provided in the input, so use the security kernel packages published by the relevant Linux distribution, device vendor, or kernel maintainer and confirm that the patch for CVE-2026-31498 is included. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, restricting Bluetooth pairing and discoverability, limiting local users who can access Bluetooth management interfaces, and disabling Bluetooth ERTM if operationally acceptable, for example through the kernel/module parameter commonly exposed as disable_ertm. Mitigations should be treated as temporary because the primary fix is the corrected kernel code path.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and package changelog against the vendor advisory for this vulnerability, not just the installed package version if the system has not rebooted. Ensure the host has booted into the patched kernel using commands such as uname -a and the distribution’s package manager query tools. If Bluetooth is not required, validate that the Bluetooth controller and service are disabled and cannot be re-enabled by unprivileged users. If using ERTM mitigation, verify the runtime parameter, commonly /sys/module/bluetooth/parameters/disable_ertm, reflects the intended value. Exposure testing should check whether Bluetooth is enabled, whether L2CAP/ERTM functionality is reachable, and whether untrusted local users or nearby peers can initiate relevant Bluetooth sessions. Avoid destructive proof-of-concept testing on production systems because exploitation is intended to exhaust memory.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and a vulnerable kernel build.
2. Gain local low-privileged ability to use Bluetooth interfaces or establish/control a Bluetooth L2CAP peer/channel accepted by the target.
3. Create an L2CAP channel using Enhanced Retransmission Mode and complete initial configuration.
4. Send crafted L2CAP CONFIG_REQ messages while the channel is already in BT_CONNECTED state to trigger repeated ERTM reinitialization and kernel memory leaks.
5. Optionally include a malformed max_pdu_size/RFC option that causes remote_mps to become zero and leads to a non-terminating segmentation loop.
6. Repeat or sustain the interaction until kernel memory is exhausted.
7. Cause denial of service through OOM kills, degraded Bluetooth operation, application crashes, or host instability.

How to detect it

Look for evidence of memory exhaustion occurring near Bluetooth activity. Useful sources include kernel logs, journalctl output, syslog, dmesg, audit logs for Bluetooth management commands, endpoint telemetry, and Bluetooth packet captures from tools such as btmon if available. Investigate OOM killer events, page allocation failures, sudden growth in kernel memory/slab usage, Bluetooth service resets, or host hangs that coincide with L2CAP configuration traffic. In packet captures, look for repeated L2CAP CONFIG_REQ messages on an already established channel, especially requests carrying an RFC/max_pdu_size option with a zero or invalid value. On affected systems, also review whether local users executed Bluetooth tooling shortly before instability. There are no unique file drops or persistent malware artifacts inherent to this vulnerability; detection is primarily behavioral and log-based.

• Out of memory: Killed process
• invoked oom-killer
• page allocation failure
• Memory cgroup out of memory
• kernel: Bluetooth:
• Bluetooth: L2CAP
• l2cap_config_req
• l2cap_parse_conf_req
• l2cap_segment_sdu
• max_pdu_size 0
• remote_mps 0
• CONFIG_REQ
• L2CAP Config Request
• /sys/module/bluetooth/parameters/disable_ertm
• btmon
• bluetoothd

What your security team should do

• Prioritize patching Linux systems with Bluetooth enabled, especially endpoints, embedded devices, shared workstations, kiosks, and appliances where untrusted users or devices may interact with Bluetooth.
• Use vendor-supported kernel updates and reboot into the fixed kernel; track remediation by running kernel version, not only installed package inventory.
• If patching is delayed, disable Bluetooth where not business-critical or disable ERTM if compatible with operational requirements.
• Restrict Bluetooth pairing, discoverability, and local Bluetooth management permissions to trusted users and devices.
• Monitor for unexplained OOM events, Bluetooth-related kernel warnings, sudden memory exhaustion, and repeated L2CAP configuration activity.
• Because EPSS is very low, exploit maturity is listed as none, and the vulnerability is not in KEV, treat this as availability hardening rather than an emergency internet-scale exploitation event unless local exposure is high.
• Add this issue to kernel vulnerability management workflows for downstream Linux distributions and embedded firmware images that may lag upstream kernel fixes.