CVE-2026-19939

Source
https://cve.org/CVERecord?id=CVE-2026-19939
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-19939.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2026-19939
Aliases
  • GHSA-9mww-f3h4-mq95
Published
2026-10-13T16:39:16Z
Modified
2026-10-14T02:48:28Z
Severity
  • 6.3 (Medium) CVSS_V3 - CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H CVSS Calculator
Summary
Bluetooth Classic AVDTP: stale timeout work on signalling-channel disconnect leads to kernel timeout-list corruption
Details

The AVDTP signalling layer arms a 6-second command timeout (AVDTP_TIMEOUT) in avdtp_send_cmd() whenever the local device issues an AVDTP request. Every response handler in subsys/bluetooth/host/classic/avdtp.c cancels session->timeout_work before clearing the pending request, but bt_avdtp_l2cap_disconnected() only cleared session->req and left the delayable work armed. The struct bt_avdtp session is the first member of struct bt_a2dp, whose instances live in a static per-connection array, and a2dp_get_connection() in subsys/bluetooth/host/classic/a2dp.c wipes a slot with memset() as soon as session->br_chan.chan.conn is NULL — which the L2CAP layer arranges immediately after the disconnect callback returns.

A remote Bluetooth BR/EDR peer triggers the condition by opening the AVDTP signalling channel, letting the local application issue an AVDTP procedure (the standard A2DP flow issues bt_a2dp_discover() from the connected callback), then tearing the signalling channel down without responding and re-opening it within the remaining timeout window. The reconnect reaches a2dp_accept() → a2dp_get_connection(), which zeroes the whole struct bt_a2dp while the work item's struct _timeout is still linked into the kernel's global timeout list. Both the disconnect and the reconnect instants are chosen by the attacker, so no race has to be won; an encrypted BR/EDR link is required, and CONFIG_BT_A2DP (experimental) must be enabled.

With the default CONFIG_TIMEOUT_BACKEND_DLIST backend the kernel decides a timeout is inactive by testing whether its list node is linked, so after the memset() the kernel treats a node that is still on the global timeout list as free: the announce path pops a node whose links and handler pointer are NULL, and the next bt_work_reschedule() on the recycled session re-inserts the same node into a list that already contains it. The consequence is corruption of the single kernel data structure every timer, timeslice and sleep depends on — writes through zeroed or stale list pointers and a NULL handler dispatch — producing a system-wide crash or hang rather than a fault confined to the A2DP session.

The fix cancels session->timeout_work at the top of bt_avdtp_l2cap_disconnected() and moves k_work_init_delayable() from avdtp_send_cmd() to the session-establishment paths bt_avdtp_connect() and bt_avdtp_l2cap_accept(), so the work item is always initialized before a disconnect callback can run.

Database specific
{
    "cna_assigner":  "zephyr",
    "cwe_ids":  [
        "CWE-825"
    ],
    "osv_generated_from":  "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/19xxx/CVE-2026-19939.json"
}
References

Affected packages

Git / github.com/zephyrproject-rtos/zephyr

Affected ranges

Type
GIT
Repo
https://github.com/zephyrproject-rtos/zephyr
Events
Database specific
Show details
{
    "extracted_events":  [
        {
            "introduced":  "3.7.0"
        },
        {
            "last_affected":  "4.4.2"
        }
    ],
    "source":  "AFFECTED_FIELD"
}

Affected versions

v3.*
v3.7.0
v4.*
v4.0.0
v4.0.0-rc1
v4.0.0-rc2
v4.0.0-rc3
v4.1.0
v4.1.0-rc1
v4.1.0-rc2
v4.1.0-rc3
v4.2.0
v4.2.0-rc1
v4.2.0-rc2
v4.2.0-rc3
v4.3.0
v4.3.0-rc1
v4.3.0-rc2
v4.3.0-rc3
v4.4.0
v4.4.0-rc1
v4.4.0-rc2
v4.4.0-rc3
v4.4.1
v4.4.1-rc1
v4.4.2
v4.4.2-rc1

Database specific

source
"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-19939.json"