CVE-2026-19940: Bluetooth HFP AG reuses a connection slot while a delayable work item is still armed, corrupting kernel timeout bookkeeping
The Bluetooth Classic Hands-Free Profile Audio Gateway implementation in subsys/bluetooth/host/classic/hfpag.c keeps its struct bthfpag objects in a static pool indexed by ACL connection index. On link teardown, hfpagdisconnected() cancels ag->txwork and the per-call work items and then clears ag->aclconn, which marks the pool slot as free — but it leaves ag->ongoingcallwork (and ag->slcwork) untouched. The next connection that lands on the same slot enters hfpagcreate(), whose only occupancy test is ag->aclconn, and immediately executes memset(ag, 0, sizeof(struct bthfpag)) followed by kworkinitdelayable(). Zeroing and re-initialising a kworkdelayable whose struct timeout node is still linked into the kernel timeout list leaves the kernel holding a reference to a node with NULL prev/next links.
ag->ongoingcallwork is armed by the remote peer: when a Hands-Free unit sends AT+CIND? during Service Level Connection establishment and the application provides the asynchronous getongoingcall callback, the AG schedules the work for CONFIGBTHFPAGGETONGOINGCALLTIMEOUT milliseconds (default 10000). The timer is cancelled only if the application answers in time via bthfpagongoingcalls(). A peer that sends AT+CIND?, then disconnects the HFP RFCOMM DLC, then immediately re-opens it on the same ACL link, reuses the same pool slot deterministically while the timeout is still pending — the AG's RFCOMM server accept path (hfpagaccept()) calls hfpagcreate() directly, so the remote side drives both teardown and re-creation.
The result is corruption of the kernel's timeout list: sysdlistremove() on the zeroed node performs writes through NULL pointers from the clock-announce path, and rescheduling the re-initialised work re-inserts a node the list already references, creating a cycle that the announce loop walks with interrupts locked. The observable impact is a fault or hang of the whole system, i.e. a denial of service reachable from Bluetooth radio range; no attacker-controlled data is written, so this does not by itself yield code execution. Exposure is limited to builds with CONFIGBTHFPAG (marked experimental and disabled by default) whose application implements the asynchronous getongoingcall callback.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using the Zephyr Bluetooth Classic Hands-Free Profile Audio Gateway are affected when the application provides the asynchronous get_ongoing_call callback. The vulnerable work item is scheduled during Service Level Connection establishment after a remote Hands-Free unit sends AT+CIND?.
What does an attacker need to do to trigger the vulnerable state?
A remote Hands-Free unit must cause the Audio Gateway to schedule ongoing_call_work with AT+CIND?, then the connection must be torn down while that delayed work remains armed. A subsequent connection must reuse the same ACL connection pool slot before the outstanding timeout is resolved or cancelled.
Is the vulnerable timeout enabled under the default timeout configuration?
Yes. When the asynchronous callback path is used, ongoing_call_work is scheduled for CONFIG_BT_HFP_AG_GET_ONGOING_CALL_TIMEOUT milliseconds, whose stated default is 10000 milliseconds. The work is cancelled if the application supplies the ongoing-call response in time.