Answer in brief
CVE-2026-90089 records a Unknown severity vulnerability in Bluetooth: btnxpuart: Validate the FW dump header length. 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 | >=998e447f443f138c90faa6ff3845082af419070e <a644b8df94966b672ac656577df98bd01bc88393 || >=998e447f443f138c90faa6ff3845082af419070e <22d419db7f9a01bea22cfcf66774d2b2fd4bb354 || >=998e447f443f138c90faa6ff3845082af419070e <060fa7592bdc043a93b6b7870f5b8551206d315d | a644b8df94966b672ac656577df98bd01bc88393, 22d419db7f9a01bea22cfcf66774d2b2fd4bb354, 060fa7592bdc043a93b6b7870f5b8551206d315d |
| Linux/Linuxgeneric | 6.15 | Not reported |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Validate the FW dump header length nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated.
Quoted source text, attributed separately from HOL analysis.