Клиентская функция GATT хоста Bluetooth parse_read_std_char_desc() в subsys/bluetooth/host/gatt.c анализирует ответ ATT Read By Type, полученный от удаленного сервера GATT во время обнаружения BT_GATT_DISCOVER_STD_CHAR_DESC. Шаг rsp->len для каждого входа берется непосредственно из PDU однорангового узла, и цикл синтаксического анализа одновременно проверяет условие выхода (длина >= rsp->len) и продвигается вперед (длина -= rsp->len, pdu += rsp->len), используя это значение. Минимальное значение rsp->len никогда не проверялось перед циклом.
Злонамеренный или неисправный узел может ответить rsp->len = 0. Поскольку длина не имеет знака и никогда не уменьшается, условие цикла остается истинным навсегда, и указатель чтения никогда не перемещается вперед; Пока тело состоит из хотя бы нескольких байтов с ненулевым дескриптором и соответствующим UUID дескриптора, хост неоднократно повторно анализирует одни и те же байты и вызывает обратный вызов обнаружения, никогда не завершаясь. Это зависает поток обработки хоста Bluetooth (CWE-835, цикл с недостижимым условием выхода).
Условие становится доступным любому подключенному узлу, как только локальное устройство инициирует обнаружение значения стандартного дескриптора; Обнаружение GATT не требует связывания или шифрования, поэтому его может запустить неаутентифицированный соседний злоумышленник, к которому подключается устройство. Результатом является отказ в обслуживании подсистемы Bluetooth (и, вероятно, сброс сторожевого таймера на ограниченных целях); нет раскрытия или повреждения памяти. Исправление добавляет проверку rsp->len < sizeof(struct bt_att_data) перед циклом, отклоняя ответы недостаточной длины, поэтому шаг всегда ненулевой и цикл завершается.
Родственные парсеры parse_include() и parse_characteristic() уже проверили rsp->len и не затронуты.
Показать оригинальное описание (EN)
The Bluetooth host GATT client function parse_read_std_char_desc() in subsys/bluetooth/host/gatt.c parses an ATT Read By Type Response received from a remote GATT server during BT_GATT_DISCOVER_STD_CHAR_DESC discovery. The per-entry stride rsp->len is taken directly from the peer's PDU, and the parse loop both tests its exit condition (length >= rsp->len) and advances (length -= rsp->len, pdu += rsp->len) using that value. The minimum value of rsp->len was never validated before the loop. A malicious or malfunctioning peer can reply with rsp->len = 0. Because length is unsigned and never decreases, the loop condition stays true forever and the read pointer never advances; as long as the body is at least a few bytes with a non-zero handle and a matching descriptor UUID, the host repeatedly re-parses the same bytes and invokes the discovery callback, never terminating. This hangs the Bluetooth host processing thread (CWE-835, loop with unreachable exit condition). The condition is reachable by any connected peer once the local device initiates standard-descriptor-value discovery; GATT discovery does not require bonding or encryption, so an unauthenticated adjacent attacker that the device connects to can trigger it. The impact is denial of service of the Bluetooth subsystem (and likely a watchdog reset on constrained targets); there is no memory disclosure or corruption. The fix adds a rsp->len < sizeof(struct bt_att_data) check before the loop, rejecting under-length responses so the stride is always non-zero and the loop terminates. The sibling parsers parse_include() and parse_characteristic() already validated rsp->len and are unaffected.
Характеристики атаки
Последствия
Строка CVSS v3.1