Look up another CVE · open CVE-2026-90089 in the interactive tracker
CVE-2026-90089
Bluetooth: btnxpuart: Validate the FW dump header length
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/bluetooth. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-90089 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/bluetooth/btnxpuart.c
- What this is
- NXP BLUETOOTH WIRELESS DRIVERSMAINTAINERS section matched on drivers/bluetooth/btnxpuart.c · Maintained
Check it on the machine
grep -wE 'CONFIG_BT|CONFIG_BT_NXPUART' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code in 3 releases. The build rule could not be established for 1 release, so nothing is claimed about those.
- bookworm?
- trixie, forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switches
- CONFIG_BT, CONFIG_BT_NXPUART
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.1 high
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:Hsource recompute it - Attack vector
- adjacent network (AV:A)source
- EPSS
- 0.33%, higher than 24.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/bluetooth
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.52 | a644b8df9496 |
| 6.15 | 7.2.6 | 22d419db7f9a |
| 6.15 | 7.3 | 060fa7592bdc |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:AAttack vector, adjacent network
- The malformed nxp_fw_dump_hdr is taken from HCI ACL frames with connection handle 0xFFF. Those frames are assembled by h4_recv_buf() from UART bytes in btnxpuart_receive_buf() and dispatched by nxp_recv_acl_pkt() into nxp_process_fw_dump(). A nearby attacker who induces an NXP firmware dump over the air supplies that ACL dump chunk; Bluetooth range is Adjacent.
- AC:LAttack complexity, low
- nxp_process_fw_dump() loads seq_num and buf_len after skb_pull_data() of only the 4-byte HCI ACL header. h4_recv_buf() delivers any dlen the controller advertised, including zero, so one handle-0xFFF ACL with dlen<8 deterministically over-reads with no race or uninfluenced layout.
- PR:NPrivileges required, none
- nxp_recv_acl_pkt() and nxp_process_fw_dump() run on the serdev RX path with no pairing, HCI authentication, or capability check; handle 0xFFF dump chunks are consumed before they reach the normal HCI ACL stack.
- UI:NUser interaction, none
- btnxpuart_receive_buf() always passes complete H4 ACL frames to nxp_recv_acl_pkt(); no user must pair, confirm a prompt, or write the HCI coredump sysfs entry for a dump chunk to be parsed.
- S:UScope, unchanged
- The over-read, hci_devcd_init/append/complete dump state, and nxp_set_ind_reset() controller reset all stay in the host kernel's btnxpuart/HCI authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:LConfidentiality impact, low
- After pulling the ACL header, the driver loads the 8-byte nxp_fw_dump_hdr (seq_num and buf_len) from skb->data even when skb->len is 0–7. That is a strictly bounded 8-byte over-read of the H4 ACL skb tailroom allocated at HCI_MAX_FRAME_SIZE, and those fields are never copied to userspace.
- I:NIntegrity impact, none
- The path only reads seq_num/buf_len to decide dump start/complete and does not write past the skb; hci_devcd_append() copies only skb->len valid bytes, so there is no OOB write or control-flow hijack primitive.
- A:HAvailability impact, high
- When the over-read buf_len is 0, nxp_process_fw_dump() calls hci_devcd_complete() and nxp_set_ind_reset(), which injects HCI_EV_HARDWARE_ERROR 0xb0 (BTNXPUART_IR_HW_ERR) and runs the independent-reset path (nxp_hw_err → HCI_NXP_IND_RESET), taking the Bluetooth controller down; a truncated handle-0xFFF frame can repeat this at will.