CVE-2026-31498
Received Received - Intake
Infinite Loop and Resource Leak in Linux Bluetooth L2CAP ERTM

Publication date: 2026-04-22

Last updated on: 2026-04-28

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED state to support L2CAP reconfiguration (e.g. MTU changes). However, since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from the initial configuration, the reconfiguration path falls through to l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and retrans_list without freeing the previous allocations and sets chan->sdu to NULL without freeing the existing skb. This leaks all previously allocated ERTM resources. Additionally, l2cap_parse_conf_req() does not validate the minimum value of remote_mps derived from the RFC max_pdu_size option. A zero value propagates to l2cap_segment_sdu() where pdu_len becomes zero, causing the while loop to never terminate since len is never decremented, exhausting all available memory. Fix the double-init by skipping l2cap_ertm_init() and l2cap_chan_ready() when the channel is already in BT_CONNECTED state, while still allowing the reconfiguration parameters to be updated through l2cap_parse_conf_req(). Also add a pdu_len zero check in l2cap_segment_sdu() as a safeguard.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-22
Last Modified
2026-04-28
Generated
2026-05-07
AI Q&A
2026-04-22
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 20 associated CPEs
Vendor Product Version / Range
linux linux_kernel 5.7
linux linux_kernel From 4.14.200 (inc) to 4.15 (exc)
linux linux_kernel From 4.19.149 (inc) to 4.20 (exc)
linux linux_kernel From 4.4.238 (inc) to 4.5 (exc)
linux linux_kernel From 4.9.238 (inc) to 4.10 (exc)
linux linux_kernel From 5.4.69 (inc) to 5.5 (exc)
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel 7.0
linux linux_kernel From 5.11 (inc) to 5.15.203 (exc)
linux linux_kernel From 5.7.1 (inc) to 5.10.253 (exc)
linux linux_kernel From 5.16 (inc) to 6.1.168 (exc)
linux linux_kernel From 6.13 (inc) to 6.18.21 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.11 (exc)
linux linux_kernel From 6.2 (inc) to 6.6.131 (exc)
linux linux_kernel From 6.7 (inc) to 6.12.80 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-835 The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's Bluetooth L2CAP implementation. It involves improper handling during the re-initialization of Enhanced Retransmission Mode (ERTM) resources when reconfiguring L2CAP channels that are already connected.

Specifically, the function l2cap_config_req() processes configuration requests for channels in the BT_CONNECTED state. Because certain flags are already set from the initial configuration, the code mistakenly re-initializes ERTM resources without freeing previously allocated memory, causing resource leaks.

Additionally, the function l2cap_parse_conf_req() does not validate a minimum value for the remote maximum PDU size (remote_mps). If this value is zero, it leads to an infinite loop in l2cap_segment_sdu() because the loop's termination condition is never met, which results in exhaustion of available memory.

The fix involves skipping the re-initialization steps when the channel is already connected, while still allowing configuration updates, and adding a check to prevent zero pdu_len values to avoid infinite loops.


How can this vulnerability impact me? :

This vulnerability can lead to memory leaks and potentially cause the system to exhaust available memory due to an infinite loop triggered by a zero pdu_len value.

Such memory exhaustion can degrade system performance, cause instability, or lead to denial of service conditions in devices using the affected Linux kernel Bluetooth stack.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by skipping the re-initialization of ERTM resources when the channel is already in the BT_CONNECTED state, and by adding a zero check for pdu_len to prevent infinite loops.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart