Answer in brief
CVE-2026-89583 records a Unknown severity vulnerability in Bluetooth: eir: Fix OOB read in eir_get_service_data(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=8f9ae5b3ae80f168a6224529e3787f4fb27f299a <815fc98c227a78cbd93d4c29f2833705b7c2bc0f || >=8f9ae5b3ae80f168a6224529e3787f4fb27f299a <c21fa79301d7d6ac0a4ec6c51e8ba10beaa08c50 || >=8f9ae5b3ae80f168a6224529e3787f4fb27f299a <bb56e97bd67614238c1c0a4084704ccadbb875b4 || >=8f9ae5b3ae80f168a6224529e3787f4fb27f299a <4beb198bc59b242404a47c21990bc84165052c8a | 815fc98c227a78cbd93d4c29f2833705b7c2bc0f, c21fa79301d7d6ac0a4ec6c51e8ba10beaa08c50, bb56e97bd67614238c1c0a4084704ccadbb875b4, 4beb198bc59b242404a47c21990bc84165052c8a |
| Linux/Linuxgeneric | 5.19 | Not reported |
Published upstream
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 11, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 11, 2026
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: eir: Fix OOB read in eir_get_service_data() eir_get_service_data() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances: eir += dlen; eir_len -= dlen; eir_get_data() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eir_len does not, and the shortfall compounds across fields until eir_get_data() reads the length and type bytes of a "field" past the end of the buffer. For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hci_conn. A drifted field that matches the BAA UUID puts those bytes in iso_pi(sk)->base, where user space reads them back with getsockopt(BT_ISO_BASE). Recompute eir_len from the end of the buffer each iteration.
Quoted source text, attributed separately from HOL analysis.