PT-2026-146863

CVE-2026-92241

·

Publicado

2026-11-13

·

Atualizado

2026-11-13

Descrição por

CVSS 3.1
5.7
Média
MétricasAV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
The AVRCP browsing channel's L2CAP receive-buffer callback, browsing avrcp l2cap alloc buf() in subsys/bluetooth/host/classic/avrcp.c, allocated from the shared avctp browsing rx pool with K FOREVER. L2CAP invokes that callback from the Bluetooth RX work queue thread (bt workq, "BT RX WQ"), both for the head buffer of a new SDU and — through l2cap br alloc frag() and net buf append bytes() — for every further fragment of a reassembled SDU. That same thread is the only context that ever releases these buffers, after bt l2cap br recv seg() delivers a completed SDU and calls net buf unref(), so a wait taken there can never be satisfied.
The pool holds CONFIG BT MAX CONN + 1 buffers of CONFIG BT AVRCP BROWSING L2CAP MTU bytes (two buffers of 339 bytes in the default configuration). A connected browsing peer can drain it because bt l2cap br recv seg() in subsys/bluetooth/host/classic/l2cap br.c accepts the SDU length declared in an SAR START segment without bounding it by br chan->rx.mtu: a peer that announces a large SDU and then streams continuation segments forces one pool buffer per segment-worth of data. Once the pool is empty the next allocation blocks forever inside the callback.
Triggering the flaw requires a build with CONFIG BT CLASSIC and the experimental CONFIG BT AVRCP BROWSING option, an application that registers AVRCP callbacks, and a BR/EDR peer that has established the AVRCP control channel and then the browsing channel, which requires an encrypted (paired) link. No malformed packet is needed — a few hundred bytes of ordinary segmented L2CAP traffic suffice.
The consequence is a permanent hang of the whole Bluetooth host, not just of AVRCP: the blocked thread drains bt dev.rx queue for all HCI ACL data and low-priority events and also runs the host's internal work items, so all connections stop being serviced and the state is unrecoverable without a reboot. There is no memory-corruption or information-disclosure component. The fix allocates with K NO WAIT, so an empty pool now yields a local-busy indication or a channel disconnect that the application can recover from.
Explorabilidade
Correção
Fornecedores
Produtos afetados
Enumeração de fraquezas
Identificadores relacionados
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾