]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop
authorHyunwoo Kim <imv4bel@gmail.com>
Fri, 20 Mar 2026 11:23:10 +0000 (20:23 +0900)
committerLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Wed, 25 Mar 2026 19:32:32 +0000 (15:32 -0400)
commit25f420a0d4cfd61d3d23ec4b9c56d9f443d91377
tree5b2c2fdbeb4b5dad18177ec078b45f30f001a1ec
parent00fdebbbc557a2fc21321ff2eaa22fd70c078608
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.

Fixes: 96298f640104 ("Bluetooth: L2CAP: handle l2cap config request during open state")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
net/bluetooth/l2cap_core.c