Improper validation of LL_CONNECTION_UPDATE_IND latency allows remote DoS via integer wraparound

[wqqqy]

Dear developers,

We recently identified a potential issue in the Nimble controller. Please let us know if you need any additional information. We would also be happy to submit a patch to help resolve this issue.

Please kindly find the description and suggested fix below.

Description

Apache Mynewt NimBLE BLE Controller contains an improper input validation vulnerability in the handling of LL_CONNECTION_UPDATE_IND control PDUs.
Specifically, in ble_ll_ctrl_rx_conn_update(), the Latency field from the received control PDU is stored directly in connsm->conn_update_req.latency without validation against Bluetooth specification constraints.

Impact

A malicious or non-compliant central device can send a crafted LL_CONNECTION_UPDATE_IND with an invalid Latency value (e.g., 0xFFFF).

The malformed Latency value is first stored in connsm->conn_update_req.latency in ble_ll_ctrl_rx_conn_update(). It becomes effective when the connection event counter reaches connsm->conn_update_req.instant, at which point upd is set to &connsm->conn_update_req and upd->latency is copied into connsm->periph_latency.

The invalid value is later used in connection event scheduling logic via ble_ll_conn_next_event(). It causes an integer wraparound during connection event scheduling, leading to event_cntr_diff == 0 and triggering BLE_LL_ASSERT (event_cntr_diff > 0), resulting in a DoS.

mynewt-nimble/nimble/controller/src/ble_ll_conn.c

Lines 2522 to 2523 in 55c2d46

	event_cntr_diff = next_event_cntr - connsm->event_cntr;
	BLE_LL_ASSERT(event_cntr_diff > 0);

Specifically, we have event_cntr_diff = next_event_cntr - connsm->event_cntr

mynewt-nimble/nimble/controller/src/ble_ll_conn.c

Lines 2439 to 2464 in 55c2d46

	/*
	* XXX: TODO Probably want to add checks to see if we need to start
	* a control procedure here as an instant may have prevented us from
	* starting one.
	*/
	/*
	* XXX TODO: I think this is technically incorrect. We can allow peripheral
	* latency if we are doing one of these updates as long as we
	* know that the central has received the ACK to the PDU that set
	* the instant
	*/
	/* Set event counter to the next connection event that we will tx/rx in */
	use_periph_latency = next_is_subrated &&
	connsm->flags.periph_use_latency &&
	!connsm->flags.conn_update_sched &&
	!connsm->flags.phy_update_sched &&
	!connsm->flags.chanmap_update_sched &&
	connsm->flags.pkt_rxd;
	if (next_is_subrated) {
	next_event_cntr = base_event_cntr + subrate_factor;
	if (use_periph_latency) {
	next_event_cntr += subrate_factor * connsm->periph_latency;
	}

we have next_event_cntr = base_event_cntr + subrate_factor + subrate_factor * connsm->periph_latency

mynewt-nimble/nimble/controller/src/ble_ll_conn.c

Lines 2435 to 2436 in 55c2d46

	base_event_cntr = connsm->event_cntr;
	subrate_factor = 1;

we have base_event_cntr = connsm->event_cntr and subrate_factor = 1. So event_cntr_diff = 1 + 0xFFFF = 0x10000 -> 0.

Suggested patch for this issue

Although the Latency field is 16-bit, valid values are constrained by the Bluetooth specification. Accepting arbitrary values such as 0xFFFF violates these constraints and leads to invalid scheduling behavior.

Specifically, add input validation in ble_ll_ctrl_rx_conn_update() before storing parameters from LL_CONNECTION_UPDATE_IND. Invalid values, including malformed latency values such as 0xFFFF, should be rejected, and the connection should be terminated with BLE_ERR_INV_LMP_LL_PARM instead of allowing them to propagate into scheduling state.

As a defense-in-depth measure, validate the pending update parameters again before copying upd->latency into connsm->periph_latency. If an invalid state is still detected during scheduling, terminate the connection with BLE_ERR_INV_LMP_LL_PARM instead of triggering an assertion.

Reference(s)

• Bluetooth Core Specification Vol 6, Part B, Section 4.5.1
• Apache NimBLE source:
  • ble_ll_ctrl_rx_conn_update
  • ble_ll_conn_next_event
  • ble_ll_conn_event_end
  • connsm->conn_update_req.latency
  • connsm->periph_latency

Additional info
We identified this issue by rehosting the NimBLE controller and performing over-the-air–like testing with injected malformed Link Layer control PDUs.