From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-89583][MODERATE 7.0] Bluetooth: eir: Fix OOB read in eir_get_service_data() Date: Fri, 11 Sep 2026 19:01:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-89583 X-AL-KERNEL-Priority: MODERATE 7.0 X-AL-KERNEL-Severity: MODERATE 7.0 X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: YES X-AL-KERNEL-ActionableScore: 6 X-AL-KERNEL-ActionableScore-Lower: 5 X-AL-KERNEL-Commit: 815fc98c227a78cbd93d4c29f2833705b7c2bc0f List-Id: CVE: CVE-2026-89583 Priority: MODERATE 7.0 AL-KERNEL base severity: MODERATE KPANIC flag: YES Patch: Bluetooth: eir: Fix OOB read in eir_get_service_data() Commit: 815fc98c227a78cbd93d4c29f2833705b7c2bc0f Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=815fc98c227a78cbd93d4c29f2833705b7c2bc0f Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89583 Analysis date: Fri, 11 Sep 2026 19:01:50 -0400 ActionableScore: 6 ActionableScore lower bound: 5 Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review Manual review required: YES Summary: A Bluetooth EIR parser length accounting bug allows a nearby LE broadcaster to trigger an OOB read from periodic advertising data into adjacent hci_conn kernel state, with bytes potentially exposed to userspace through BT_ISO_BASE. ====================================================================== ABOUT THIS REPORT ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89583 is available here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89583 The original announcement does not normally provide a security severity estimate, CVSS assessment, or enough information to determine whether the reported kernel bug represents a practically relevant security issue. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. It combines an autonomous classifier with LLM-assisted technical analysis and a separate ActionableScore mechanism. The purpose of this report is to prioritize Linux kernel CVEs before manual review, identify cases that require prompt investigation, and support automatic closure of issues that are unlikely to have meaningful security impact. Published priority for this report: MODERATE 7.0 Manual review required: YES A detailed explanation of the methodology and priority rules is included at the end of this message. ====================================================================== AL-KERNEL CLASSIFICATION RESULT ====================================================================== CVE-2026-89583 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-89583 CHECK WITH IMPACT FROM ORIG NN MODERATE Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L';CWE-125;*CWE-200;*CWE-20;Other CVSS 'AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N';BEST CVSS score: '7.1';DESCR 'An OOB read in Bluetooth eir_get_service_data occurs because the parser advances the EIR pointer after a UUID mismatch but keeps an incorrect remaining length. A crafted periodic advertising payload from a nearby Bluetooth LE broadcaster can make the parser walk past hcon le_per_adv_data into adjacent bytes of struct hci_conn. If the drifted field is interpreted as matching the BAA UUID, those bytes can be copied into iso_pi(sk) base and exposed to user space through getsockopt(BT_ISO_BASE). For the CVSS the PR:N is used because the malformed advertising data can be supplied by a nearby broadcaster without credentials on the victim. The issue is adjacent network reachable over Bluetooth rather than Internet reachable. Impact is primarily information disclosure. Availability impact is only considered in the paranoid score because the primitive is an out of bounds read, not an out of bounds write or UAF.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 6) YES REMOTE OOB NETWORK KPANIC KPANIC INCREASED_TO_HIGH_BASED_ON_GUESSCVSS DECREASED_TO_MODERATE7_BASED_ON_FALSEPOSCHECKOFKP YES NO checked ====================================================================== ACTIONABLESCORE ANALYSIS ====================================================================== ActionableScore=6 ActionableScoreLower=5 PrimitiveClass=CLASS_A RealUAF=NO HostAdminRequired=NO NamespaceScopedPrivilege=NO ImportantCandidate=YES ManualReview=REQUIRED AutoDowngradeAllowed=NO ## 1. ActionableScore * Raw conservative score: 5 * Conservative score: 5. No floor or cap changed the score. * Raw paranoid score: 6 * Paranoid score: 6. No floor or cap changed the score. * Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**:: ## 2. Signal breakdown Positive signals: * +2 Concrete user-visible kernel disclosure primitive. The parser can read past `hcon->le_per_adv_data[]` into adjacent `struct hci_conn` bytes, and the commit describes a path where those bytes are copied into `iso_pi(sk)->base` and read back with `getsockopt(BT_ISO_BASE)`. * +2 Adjacent network trigger. The malformed periodic advertising payload is supplied by a nearby Bluetooth LE broadcaster, so attacker-controlled wireless input reaches the vulnerable parser without host-admin privilege on the victim. * +1 Practical exploit chain strongly implied. The chain is not just an internal OOB read: crafted PA payload -> length drift -> OOB read from `struct hci_conn` -> copied into ISO base -> user-visible readback. Paranoid-only signal: * +1 Higher confidentiality concern. The leaked region is adjacent kernel object state in `struct hci_conn`; depending on layout and drift, leaked bytes may include sensitive kernel state or pointer-like data. This supports stronger review, but not integrity impact. Non-awarded signals: * No UAF or lifetime violation is established. * No OOB write, arbitrary write, controlled reclaim, or privilege escalation primitive is established. * Integrity impact is not awarded because the patch shows read-only OOB access. * Extra availability is not awarded conservatively because the demonstrated primitive is disclosure, not crash. Availability remains only a possible secondary concern. * No race or timing penalty is applied. * No rare-subsystem penalty is applied solely because Bluetooth ISO broadcast is not universal. ## 3. Reachability analysis The input side is reachable from a nearby Bluetooth LE broadcaster that can send crafted periodic advertising data. This is adjacent-network reachability, not Internet reachability. Host-admin privilege is not required for the broadcaster to supply malformed advertising data to a listening or configured victim. The readback side is through local userspace via `getsockopt(BT_ISO_BASE)`, so the complete attacker model may involve either a local process observing the corrupted ISO base or an environment where attacker-controlled broadcaster input affects a local ISO sink process. The patch evidence does not establish namespace-scoped privilege relevance. Prior Bluetooth and ISO broadcast sink setup may be necessary in practice, but the supplied evidence does not prove this setup must be host-admin-only for the vulnerable parsing path. No special rare hardware beyond Bluetooth LE support is established as a scoring reducer. ## 4. Primitive and severity interpretation The exact primitive is an out-of-bounds read caused by incorrect remaining-length accounting in `eir_get_service_data()`. The pointer advances to the next field, but `eir_len` is reduced incorrectly, allowing later `eir_get_data()` parsing to operate past the original buffer. This is not memory corruption with write capability. It is a concrete read-disclosure primitive because the OOB bytes can be propagated to `iso_pi(sk)->base` and exposed to userspace. PrimitiveClass is `CLASS_A` because a kernel information disclosure path is directly established. RealUAF is `NO`. ImportantCandidate is `YES` because the issue is adjacent-network reachable and exposes kernel object bytes through a concrete readback path. AutoDowngradeAllowed is `NO` because automatically closing this as ordinary low-risk OOB read would lose a real disclosure primitive and adjacent attack surface. Operationally, this is best treated as actionable Moderate with strong manual-review justification, not as proven LPE or arbitrary kernel memory access. ## 5. One-sentence report phrase A Bluetooth EIR parser length accounting bug allows a nearby LE broadcaster to trigger an OOB read from periodic advertising data into adjacent hci_conn kernel state, with bytes potentially exposed to userspace through BT_ISO_BASE. ## 6. Manual review recommendation MANUAL CHECK REQUIRED Reason: concrete OOB read plus explicit user-visible disclosure path plus adjacent Bluetooth reachability. ## 7. Call-site confidence Call-site confidence: high ====================================================================== UPSTREAM PATCH SUMMARY ====================================================================== Patch: Bluetooth: eir: Fix OOB read in eir_get_service_data() Commit: 815fc98c227a78cbd93d4c29f2833705b7c2bc0f Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=815fc98c227a78cbd93d4c29f2833705b7c2bc0f Commit description: 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. Fixes: 8f9ae5b ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Greg Kroah-Hartman Changed files: net/bluetooth/eir.c Diff excerpt: Not included in this email. See the upstream URL for the full patch. Full patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=815fc98c227a78cbd93d4c29f2833705b7c2bc0f ====================================================================== DETAILED REPORT METHODOLOGY ====================================================================== The original Linux kernel CVE announcement for CVE-2026-89583 can be found here: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89583 The original CVE announcement normally does not include a security-level estimate. In particular, it may not contain a CVSS assessment, an impact level, or enough information to determine whether the reported bug is a practically relevant security issue. One purpose of this parallel CVE list is to provide that missing technical and prioritization information. The original goal of the AL-KERNEL project was to prioritize Linux kernel CVE analysis automatically before manual review. The system can also help identify non-security issues that may be suitable for automatic closure. This report was generated by AL-KERNEL, an AI-assisted Linux kernel vulnerability analysis system developed by Alexander Larkin. The first analysis stage combines an autonomous classifier with additional LLM-based analysis. The autonomous classifier runs locally on a CPU and is based on a backpropagation neural network. Together, these mechanisms produce a technical vulnerability description, identify likely weakness types, estimate CVSS severity, and provide input for ActionableScore. Two CVSS estimates are retained because incomplete kernel vulnerability information often permits more than one defensible interpretation: Conservative CVSS vector: AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N The Best / paranoid CVSS vector: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L The Best / paranoid CVSS score: 7.1 The conservative vector represents a lower-impact interpretation. The Best/paranoid vector intentionally represents a plausible upper-bound interpretation and should not automatically be treated as demonstrated real-world impact. CVSS may also need to be adjusted for a particular Linux deployment, because actual reachability, privileges, enabled kernel configuration, hardware, namespaces, exposed device nodes, and other environmental conditions can differ significantly between systems. A separate ActionableScore mechanism evaluates practical remediation urgency. Its analysis may include reachability, attack prerequisites, subsystem exposure, memory-corruption characteristics, denial-of-service reliability, and possible confidentiality, integrity, or privilege-escalation impact. Conservative ActionableScore: 5 Paranoid ActionableScore: 6 The final base severity is taken directly from the second tab-separated field of the AL-KERNEL classification result. ActionableScore does not replace or independently override that final AL-KERNEL decision, and if ActionableScore adjusted impact level of ALKERNEL, then you would see self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7. For an AL-KERNEL result of MODERATE, this report uses the following additional presentation split: ActionableScore below 5 -> MODERATE REGULAR ActionableScore 5 or more -> MODERATE 7.0 The distinction between MODERATE REGULAR and MODERATE 7.0 makes it possible to identify Moderate issues that should receive manual analysis and fixes before lower-priority MODERATE REGULAR issues. In many cases, MODERATE REGULAR fixes may wait for a later rebase or routine update. There is one override in which MODERATE REGULAR becomes MODERATE 7.0 even when the ActionableScore is below 5. When the AL-KERNEL result contains the KPANIC flag, a MODERATE result is always presented as MODERATE 7.0. The KPANIC flag selected with few regexps without usage of AI at all, so it helps to detect cases when Kernel Crash happens and similar (to filter False-Negative results from the LLM usage). KPANIC indicates that a reliable kernel crash, kernel panic, or similarly serious kernel availability impact was identified by the classification workflow. AL-KERNEL base severity for this report: MODERATE KPANIC detected for this report: YES Published priority for this report (same as in Subject): MODERATE 7.0 These results are intended to support engineering triage. They are machine-generated estimates, and cases marked for manual review should be validated by a human security engineer before final disposition. For more info read docs linked from here: https://kernelcve.org/ (and you can submit you own patch there to generate such a report for non-existant CVE-id yet). Note that in many cases this AI tool selects higher severity, than real is (means you can expect Importants instead of Moderate 7.0 or Moderates 7.0 instead of regular Moderates). If you see such cases, please use reply email interface to add additional manual analyses info to this particular CVE. And please, please, let me know when you see Lows instead of Importants or Important instead of Low (because particular for such cases I need to tune this AI tool to make it better for this one and next similar). My contact email for such notifications is alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).