Live › vulnerability › CVE-2026-98457
Go to dashboardA short ERTM or streaming-mode L2CAP frame over Bluetooth makes the Linux kernel read its control field and FCS past the end of the buffer. The sources do not say whether this leads to code execution or only to information leaks or crashes.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Systems running a Linux kernel with the Bluetooth L2CAP stack loaded, where a nearby or paired device can send ERTM or streaming-mode frames. Hosts without Bluetooth hardware or with the module disabled can skip it. The sources do not say which kernel versions are affected.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel builds listed in the NVD entrylsmod | grep bluetooth to see whether the Bluetooth stack is loadedmodprobe -r bluetooth) on hosts that do not need it, as a stopgap: unknown from sourcesEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: validate frame length before control and FCS access
l2cap_data_rcv() unpacks either a two-byte or four-byte control field without first ensuring that it is present. A short ERTM or streaming-mode frame can therefore cause an out-of-bounds read.
There is a second short-frame case when CRC16 is enabled. After the control field is pulled, l2cap_check_fcs() subtracts two from skb->len without checking it. If fewer than two bytes remain, the subtraction wraps; skb_trim() leaves the buffer unchanged and the subsequent FCS load reads past the logical end of the frame.
Validate that the frame contains both its control field and, when enabled, its FCS before either field is accessed.
This page as .md · .json · in your agent: get_signal("CVE-2026-98457")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.