CVE-2026-85033

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-85033", "assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad", "state": "PUBLISHED", "assignerShortName": "zephyr", "dateReserved": "2026-09-02T20:23:14.098Z", "datePublished": "2026-11-03T13:36:06.746Z", "dateUpdated": "2026-11-03T18:15:47.700Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad", "shortName": "zephyr", "dateUpdated": "2026-11-03T13:36:06.746Z"}, "title": "Bluetooth Classic AVRCP Target: missing TX cleanup on disconnect permanently stalls vendor-dependent responses and leaks them to the next peer", "descriptions": [{"lang": "en", "value": "The AVRCP Target role in subsys/bluetooth/host/classic/avrcp.c keeps its vendor-dependent response transmit state in a per-connection object selected by connection index (get_avrcp_tg()), with the per-transfer context (tid, sent_len, and the BT_AVRCP_TG_FLAG_TX_ONGOING flag) stored in the user_data of the queued response net_buf. The AVCTP teardown handler avrcp_disconnected() did not cancel tg->vd_rsp_tx_work and did not release the buffers still queued on tg->vd_rsp_tx_pending, so a link drop in the middle of a fragmented response left the buffer on the list with TX_ONGOING still set.\n\nA remote AVRCP Controller can trigger this deterministically: it issues a vendor-dependent command whose response exceeds one AVRCP fragment (for example GetElementAttributes or GetCapabilities), lets bt_avrcp_tg_vendor_tx_work() emit the START fragment, and then drops the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. The AVCTP control channel requires an encrypted BR/EDR link (BT_SECURITY_L2), so the attacker must be a paired peer within radio range; no user interaction is needed.\n\nBecause the Target objects are static and reused, the next connection landing on the same connection index finds the stale buffer at the head of vd_rsp_tx_pending. Every run of the TX work sees TX_ONGOING and returns immediately, so all further vendor-dependent responses queue behind the stale head and are never sent \u2014 a persistent loss of AVRCP Target function that no timeout clears and only a reboot recovers. Each cycle also leaks one response buffer from a shallow application pool, and a new peer that sends REQUEST_CONTINUING_RESPONSE clears the stale TX_ONGOING via bt_avrcp_tg_process_continuing_cmd(), causing the un-sent remainder of the previous peer's response to be transmitted to it.\n\nThe fix cancels tg->vd_rsp_tx_work and unrefs every buffer on tg->vd_rsp_tx_pending in avrcp_disconnected(); since the TX context lives in the buffer user_data, releasing the buffers also resets the TX state machine. There is no memory corruption: the pre-fix buffer is leaked with a live reference, so no use-after-free arises."}], "affected": [{"vendor": "zephyrproject", "product": "zephyr", "collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "packageName": "zephyr", "defaultStatus": "unaffected", "programFiles": ["subsys/bluetooth/host/classic/avrcp.c"], "programRoutines": [{"name": "avrcp_disconnected"}, {"name": "bt_avrcp_tg_process_continuing_cmd"}, {"name": "bt_avrcp_tg_vendor_tx_work"}], "versions": [{"version": "4.4.0", "status": "affected", "versionType": "semver", "lessThan": "4.5.0"}]}], "references": [{"url": "https://github.com/zephyrproject-rtos/zephyr/commit/47728746bb52863607f06072c13a0a524ad6b654", "name": "Fix commit", "tags": ["patch"]}, {"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2fqc-xhj4-qvp7", "name": "GHSA-2fqc-xhj4-qvp7"}], "metrics": [{"format": "CVSS", "cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L", "baseScore": 4.6, "baseSeverity": "MEDIUM"}}], "problemTypes": [{"descriptions": [{"lang": "en", "description": "dos", "cweId": "CWE-459", "type": "CWE"}]}], "x_generator": {"engine": "cvelib 1.8.0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2026-11-03T18:15:37.681298Z", "id": "CVE-2026-85033", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-03T18:15:47.700Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2026-85033", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-11-03T18:15:37.681298Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-03T18:15:44.501Z"}}], "cna": {"title": "Bluetooth Classic AVRCP Target: missing TX cleanup on disconnect permanently stalls vendor-dependent responses and leaks them to the next peer", "metrics": [{"format": "CVSS", "cvssV3_1": {"version": "3.1", "baseScore": 4.6, "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L"}}], "affected": [{"vendor": "zephyrproject", "product": "zephyr", "versions": [{"status": "affected", "version": "4.4.0", "lessThan": "4.5.0", "versionType": "semver"}], "packageName": "zephyr", "programFiles": ["subsys/bluetooth/host/classic/avrcp.c"], "collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "defaultStatus": "unaffected", "programRoutines": [{"name": "avrcp_disconnected"}, {"name": "bt_avrcp_tg_process_continuing_cmd"}, {"name": "bt_avrcp_tg_vendor_tx_work"}]}], "references": [{"url": "https://github.com/zephyrproject-rtos/zephyr/commit/47728746bb52863607f06072c13a0a524ad6b654", "name": "Fix commit", "tags": ["patch"]}, {"url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2fqc-xhj4-qvp7", "name": "GHSA-2fqc-xhj4-qvp7"}], "x_generator": {"engine": "cvelib 1.8.0"}, "descriptions": [{"lang": "en", "value": "The AVRCP Target role in subsys/bluetooth/host/classic/avrcp.c keeps its vendor-dependent response transmit state in a per-connection object selected by connection index (get_avrcp_tg()), with the per-transfer context (tid, sent_len, and the BT_AVRCP_TG_FLAG_TX_ONGOING flag) stored in the user_data of the queued response net_buf. The AVCTP teardown handler avrcp_disconnected() did not cancel tg->vd_rsp_tx_work and did not release the buffers still queued on tg->vd_rsp_tx_pending, so a link drop in the middle of a fragmented response left the buffer on the list with TX_ONGOING still set.\n\nA remote AVRCP Controller can trigger this deterministically: it issues a vendor-dependent command whose response exceeds one AVRCP fragment (for example GetElementAttributes or GetCapabilities), lets bt_avrcp_tg_vendor_tx_work() emit the START fragment, and then drops the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. The AVCTP control channel requires an encrypted BR/EDR link (BT_SECURITY_L2), so the attacker must be a paired peer within radio range; no user interaction is needed.\n\nBecause the Target objects are static and reused, the next connection landing on the same connection index finds the stale buffer at the head of vd_rsp_tx_pending. Every run of the TX work sees TX_ONGOING and returns immediately, so all further vendor-dependent responses queue behind the stale head and are never sent \u2014 a persistent loss of AVRCP Target function that no timeout clears and only a reboot recovers. Each cycle also leaks one response buffer from a shallow application pool, and a new peer that sends REQUEST_CONTINUING_RESPONSE clears the stale TX_ONGOING via bt_avrcp_tg_process_continuing_cmd(), causing the un-sent remainder of the previous peer's response to be transmitted to it.\n\nThe fix cancels tg->vd_rsp_tx_work and unrefs every buffer on tg->vd_rsp_tx_pending in avrcp_disconnected(); since the TX context lives in the buffer user_data, releasing the buffers also resets the TX state machine. There is no memory corruption: the pre-fix buffer is leaked with a live reference, so no use-after-free arises."}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-459", "description": "dos"}]}], "providerMetadata": {"orgId": "e2e69745-5e70-4e92-8431-deb5529a81ad", "shortName": "zephyr", "dateUpdated": "2026-11-03T13:36:06.746Z"}}}, "cveMetadata": {"cveId": "CVE-2026-85033", "state": "PUBLISHED", "dateUpdated": "2026-11-03T18:15:47.700Z", "dateReserved": "2026-09-02T20:23:14.098Z", "assignerOrgId": "e2e69745-5e70-4e92-8431-deb5529a81ad", "datePublished": "2026-11-03T13:36:06.746Z", "assignerShortName": "zephyr"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"collectionURL": "https://github.com/zephyrproject-rtos/zephyr", "defaultStatus": "unaffected", "packageName": "zephyr", "product": "zephyr", "programFiles": ["subsys/bluetooth/host/classic/avrcp.c"], "programRoutines": [{"name": "avrcp_disconnected"}, {"name": "bt_avrcp_tg_process_continuing_cmd"}, {"name": "bt_avrcp_tg_vendor_tx_work"}], "vendor": "zephyrproject", "versions": [{"lessThan": "4.5.0", "status": "affected", "version": "4.4.0", "versionType": "semver"}]}], "source": "vulnerabilities@zephyrproject.org"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "The AVRCP Target role in subsys/bluetooth/host/classic/avrcp.c keeps its vendor-dependent response transmit state in a per-connection object selected by connection index (get_avrcp_tg()), with the per-transfer context (tid, sent_len, and the BT_AVRCP_TG_FLAG_TX_ONGOING flag) stored in the user_data of the queued response net_buf. The AVCTP teardown handler avrcp_disconnected() did not cancel tg->vd_rsp_tx_work and did not release the buffers still queued on tg->vd_rsp_tx_pending, so a link drop in the middle of a fragmented response left the buffer on the list with TX_ONGOING still set.\n\nA remote AVRCP Controller can trigger this deterministically: it issues a vendor-dependent command whose response exceeds one AVRCP fragment (for example GetElementAttributes or GetCapabilities), lets bt_avrcp_tg_vendor_tx_work() emit the START fragment, and then drops the ACL link instead of sending REQUEST_CONTINUING_RESPONSE. The AVCTP control channel requires an encrypted BR/EDR link (BT_SECURITY_L2), so the attacker must be a paired peer within radio range; no user interaction is needed.\n\nBecause the Target objects are static and reused, the next connection landing on the same connection index finds the stale buffer at the head of vd_rsp_tx_pending. Every run of the TX work sees TX_ONGOING and returns immediately, so all further vendor-dependent responses queue behind the stale head and are never sent \u2014 a persistent loss of AVRCP Target function that no timeout clears and only a reboot recovers. Each cycle also leaks one response buffer from a shallow application pool, and a new peer that sends REQUEST_CONTINUING_RESPONSE clears the stale TX_ONGOING via bt_avrcp_tg_process_continuing_cmd(), causing the un-sent remainder of the previous peer's response to be transmitted to it.\n\nThe fix cancels tg->vd_rsp_tx_work and unrefs every buffer on tg->vd_rsp_tx_pending in avrcp_disconnected(); since the TX context lives in the buffer user_data, releasing the buffers also resets the TX state machine. There is no memory corruption: the pre-fix buffer is leaked with a live reference, so no use-after-free arises."}], "id": "CVE-2026-85033", "lastModified": "2026-11-03T19:18:11.583", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "ADJACENT_NETWORK", "availabilityImpact": "LOW", "baseScore": 4.6, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L", "version": "3.1"}, "exploitabilityScore": 2.1, "impactScore": 2.5, "source": "vulnerabilities@zephyrproject.org", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-85033", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-11-03T18:15:37.681298Z", "version": "2.0.3"}}]}, "published": "2026-11-03T14:17:38.933", "references": [{"source": "vulnerabilities@zephyrproject.org", "url": "https://github.com/zephyrproject-rtos/zephyr/commit/47728746bb52863607f06072c13a0a524ad6b654"}, {"source": "vulnerabilities@zephyrproject.org", "url": "https://github.com/zephyrproject-rtos/zephyr/security/advisories/GHSA-2fqc-xhj4-qvp7"}], "sourceIdentifier": "vulnerabilities@zephyrproject.org", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-459"}], "source": "vulnerabilities@zephyrproject.org", "type": "Secondary"}]}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[4.4.0,4.5.0)"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "zephyr", "source": "cna", "vendor": "zephyrproject"}, "product": "zephyr", "vendor": "zephyrproject"}], "created": "2026-11-03T14:45:17.634673+00:00", "updated": "2026-11-03T14:45:17.840293+00:00", "vendors": ["zephyrproject", "zephyrproject$PRODUCT$zephyr"]}